Move pub/sub operations out of lock transaction

[Li Ma]

Currently, we implement distributed lock to protect the API session, like

obtain_lock
    do neutron db operations
    do df db operations
    send messages via pub/sub
release_lock

Actually, we need to remove pub/sub out of the lock transaction.
Because if pub/sub fails but db is updated successfully, we do not want to
rollback the db operations. We can issue another message to notify db updates.

As a result, the distributed lock protects the db transactions to make it consistent.
If pub/sub fails, we need to make it stable to avoid the errors, but not rollback the whole db transactions.

[Li Ma (nick-ma-z)]

The discussion is in the thread: https://review.openstack.org/#/c/300877/

[Eyal Leshem (leyal)]

The bug description was relevant when DF was an L3 plugin .

While DF move to be a mech-driver - all neutron DB operation done between the pre-commit to the post commit method, so Dragonflow can't warp neutron db transactions at all.

The mech-driver can only throw exceptions in the pre-commit stage - and also in the post-commit stage.

Exceptions in the pre-commit stage will lead to cancel the transaction.
Exception in the post-commit-stage (when writing to DF-DB occurs) - will cause to behavior that depends on the plugin implementation.
(for example : in create_network exception in the post-commit will delete the action ,but in update- exception throwing exception in the post-commit will do nothing).

Anyway we can still move out the publish-subscribe mech out of the DF-db-lock ..