The Topology type could be refactored to use channels instead of locks (similar to the connection pool refactor in RUST-556). This refactor would allow us to more effectively leverage the async capabilities of the driver and hopefully make the SDAM machinery easier to reason about.

Proposed layout:

• Creating Topology starts a worker task that runs in the background, and the initialized Topology struct then serves as a handle to this task. The Topology contains a mpsc::Sender and a watch::Receiver, and the task holds on to the other ends of those channels. The task will stop running once all the watch::Receiver s are dropped (i.e. all the Topology are dropped).
• Monitors send updated server descriptions over the mpsc::Sender. The task receives these descriptions, makes updates to the topology state, and publishes the new TopologyState via the watch::Sender. Monitors will stop executing once the receiving end of their senders are dropped (i.e. the worker task has quit)
• In server selection, the latest TopologyState is grabbed from the watch channel. If selection fails, a check is requested via the mpsc::Sender and the watch channel is waited on until a new TopologyState is published or server selection timeout is hit.

In this scheme, the worker task always has exclusive access to the mutable portions of the topology, while everything else always has immediate read access to the latest published TopologyState. This allows us to remove all locks and greatly simplify our SDAM machinery.