Fix races in db-based plugin

Fix races in db-based plugin.
Especially error recovery path and rpc notification.

For example typical db-based plug does for network creation,
- super().create_network() = QuantumDbPluginV2.create_network()
  this finishes db transaction.
  After the transaction is committed, the network is visible to outside.
  That is, list-network returns this network.
- then talk to plugin specific controller.
  This can takes a while and can fail.
- If the above fails, start new transaction to delete the network or mark it as error.

This causes race. The way to address is to introduce new status BUILD(already exists) and DELETING.

Another example. From openvswitch plugin. update_port()
- update db
  start transaction and update db.
- query db
- send notification
If two requests to update the same port are sent simaltaneously, it can result in race.
With db locking(row locking), we can assume the transactions are serialized.
But ad the next query to check if notification is necessary results can reorder the threads.
So the notifications can sent in reverse order.
OF-controller based plugins can talked to their controller during update. So possible way to address this is
- do all under single transaction
or
- serialize the update somehow if necessary