Better handling of FdbFuture lifetime and shutdown

[KrzysFR]

The current way FdbFuture* handles are mapped to Task's has some issues with race conditions with destroying the handles concurrently while they are executing, especially during mass future extinction (shutdown of a service, assert failed in a unit test, AppDomain being brought down by a test unit runner, ...)

Also, running some profiling on request heavy workloads points to the ConcurrentDictionary<..> used to store the maps handles to Tasks so that future callbacks can retrieve the original Task when they fire. Also, since FdbFuture is generic, there is multiple verison of this ConcurrentDictionary<..>, one for each kind of future (Slice, KeyValuePair<Slice, Slice>[], ...) which is probably not the best way to split them.

We need to change the approach, and have all the futures spawned by a transaction stored inside the transaction itself, so that we can have a safe way to destroy a transaction and make sure that all its futures are done. That way, calling transaction.Dispose() will make sure that everything is cleaned up.

Since a database instance already tracks its transactions, this in turns means that calling database.Dispose() will destroy all transactions AND futures associated.

The last missing piece is to track all opened database instance at the binding level, so that calling Fdb.Stop() would have a deterministic way to wait for ALL futures to complete/be destroyed before stopping the network thread (which is the one who runs the callbacks and can wakeup the FdbFuture objects).

So the shutdown scenario would look like this:

• set a global flag that forbid any new database instance to be opened
• ForEach database instance
  • set a global flag that forbid any new transaction to start
  • ForEah transaction instance
    • set a flag to stop any new future from starting
    • ForEach future instance
      • atomically TrySetCancelled and fdb_future_destroy
    • fdb_transaction_destroy
  • fdb_database_destroy (and probably cluster as well)
• fdb_stop_newtork

Hopefully, when we call fdb_stop_network, all callbacks will either have fired OR we would already have disposed the FdbFuture so that we wouldn't care for the callback to fire.