Refactor Reply usage to be unbounded

[chipsenkbeil]

There's a lot of bounded mpsc channels through distant, and this causes issues where we need to support async waiting, defining arbitrary channel sizes, and take extra care when blocking for some reason.

In reality, only the public-facing channels should be bounded to avoid poor user implementations. Granted, a blocking, bounded channel can signal a growing, unprocessed list; however, the most recent blockage seems to be coming from a ServerReply, and the thought is to not restrict replies.

We're going to start by modifying ServerReply to be non-async and non-blocking using the unbounded sender. This will also change some of the Mutex usages to be the standard library version, which tokio documentation describes as totally fine to do for data modifications (not database connections, etc) without passing across .await calls.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.