[Feature] Generate flow events for every flow added or removed

[viniarck]

Fixes #2

Description of the change

This PR added support to publish the rest of flows events to support reliably publishing events when flows are added, removed, still pending (not confirmed yet), and also handled switch connection error kytos/core.openflow.connection.error to bubble up the error to the caller. So, now flow_manager clients will be able to react accordingly and handle each event as needed based on their use case, not necessarily all clients will have to react and handle, but as they need, the events to completely handle every case are available, handling the kytos/flow_manager.flow.error event is highly encouraged though at least, as mef_eline already does.

Release notes

version [5.3.0] - 2021-11.21

Added

• Started listening to kytos/core.openflow.connection.error and propagating the error
• Added listen_to for ofpt_flow_removed
• Publish the event kytos/flow_manager.flow.removed on OFPT_FLOW_REMOVED
• Parametrized and added _id on stored flows to confirm flow operations
• Parametrized the flow on SwitchNotConnectedError exception
• Added support to update flow state and flows are confirmed by the consistency check

Changed

• Publish the event kytos/flow_manager.flow.added only when the flow is confirmed

[viniarck]

This kind of filtering here we can delegate and perform directly on a DB later as we move to a new back-end later on.

[italovalcy]

Looks good to me. Thanks for the changes, @viniarck. If I understood correctly, the flow events for added and removed were already being sent by flow_manager. However, you PR enhances the reliability of the information provided in the event, so that a flow_manager.flow.added is only sent when the flows are confirmed to be installed (same for other events). Which means that it will not introduce extra overhead of events, but instead it will only send those events when they are actually trusted to be sent.

[viniarck]

Looks good to me. Thanks for the changes, @viniarck. If I understood correctly, the flow events for added and removed were already being sent by flow_manager. However, you PR enhances the reliability of the information provided in the event, so that a flow_manager.flow.added is only sent when the flows are confirmed to be installed (same for other events). Which means that it will not introduce extra overhead of events, but instead it will only send those events when they are actually trusted to be sent.

Exactly, @italovalcy. Also, clients could leverage this accordingly to have simpler consistency checks in the future, if they can trust and rely on flow_manager with its consistency check and all of confirmation/error related events, then they'll have all the cases to either confirm that what they sent was successfully added or not as these events happen and react accordingly. There are some edge cases that you mentioned in terms of restart and how some NApps write to the DB, but hopefully we can also enhance that part in a non distant future. Thanks for reviewing.