Add lock to prevent race conditions on self._multipart_replies_flows

[italovalcy]

Fixes #26

Description of the change

The variable _multipart_replies_flows holds a dictionary of received flows per switch when using OpenFlow 1.3 multipart messages. The dictionary is updated upon receiving the KytosEvent kytos/of_core.v0x04.messages.in.ofpt_multipart_reply and can be accessible from many different threads at the same time. This situation may lead to race conditions when two or more threads handling the flows for the same switch update the all_flows at the same time, resulting on inconsistent/missing data.

This PR adds a threading.Lock mechanism to prevent race conditions at this variable.

Release notes

• Added mechanism to prevent race conditions at OF1.3 multipart reply handler

[viniarck]

LGTM. Great fix, one fewer potential race condition.

@italovalcy looks like the multipart handler of port stats also has a similar race condition vulnerability, should we map this in another issue to be fixed in another opportunity?

[italovalcy]

LGTM. Great fix, one fewer potential race condition.

@italovalcy looks like the multipart handler of port stats also has a similar race condition vulnerability, should we map this in another issue to be fixed in another opportunity?

@viniarck yes, you are right. The tests I've been running show that the port stats message usually doesn't get fragmented at the OpenVSwitch nor Noviflow switches. However, I think we should map this to be handled in the future. I've just created issue #32