Fix/issue 13

[viniarck]

Fixes #13

In addition to fixing the non strict logic matching of this func match13_no_strict, I've also changed how the delete command flows were store because of these reasons (since as a result of the match I was already dealing with the stored flows):

1. _store_changed_flows is already storing the managed flows on stored_flows, and any removed flows were already being excluded from that list, so, at that point flow_manager knows that the previous added flows are supposed to be gone, and the consistency checks, assuming that our matching logic is coherent keeping the flows on stored_flows only the expected ones, it should only be concerned with sync'ing missing OFPFC_ADD flows (and then later on we can evolve to only keep track of the state and not the command). The consistency check still keeps deleting alien flows no changes in that part.
2. Prior to this PR, if users were to send a OFPFC_DELETE that wouldn't delete any flow in the switch, the delete command would be stored in the stored_flows dict regardless, contributing to keep growing the list with a command that would be in practice not useful, and contribute to overwhelm the consistency checks. So, if a network operator needs to send a OFPFC_DELETE FlowMod to try to clean up other entries in the switch, or if any client of flow_manager misbehaves sending wrong matches, that shouldn't be something to keep track of I think, in fact, this being re-applied later with the consistency checks it could potentially delete flows that weren't supposed to, overtime this could diverge even more. OFPFC_DELETE(s) being treated stateless would lead to fewer surprises and more stability I think (since we are already tracking the OFPFC_ADD(s)).
3. The stored_flows will keep growing linearly but only proportional to the number of FlowMod OFPFC_ADD(s) with this change, and since OFPFC_DELETE won't be stored anymore then the size of the list in the worst case will be as large as the switch's table, so we likely won't hit a snowball effect here that we used to have, OFPFC_DELETE commands weren't being ever excluded in the list, so eventually it could become massive, and it could lead to other issues because they would be re-applied in some cases.

Let me know if you'd agree, or if you see any other potential issues, I could also break the PR in two if needed (took the chance to kill two birds with a single stone).

[viniarck]

Support for match with mask in some fields will be address in a next iteration #24, discussed this with Italo.

[italovalcy]

Thank you for your PR, Vinicius. Everything looks good and the refactoring to avoid storing delete commands is very much appreciated. I've checked the end-to-end tests and they had no impact by the PR.

[viniarck]

Thank you for your PR, Vinicius. Everything looks good and the refactoring to avoid storing delete commands is very much appreciated. I've checked the end-to-end tests and they had no impact by the PR.

Thanks for reviewing, Italo. Glad that the end-to-ends tests have also passed.