Make ads::client::Client sync

[cartercanedy]

This is the minimum diff required to make ads::client::Client sync. I considered making a special Error variant specific to locks, but I'm pretty sure that there's no way application code to induce a poisoned lock, and any poisons that come from standard library panics should definitely result in an aborted application.

Feel free to modify.

• Closes Making ads::client::Client implement the Send and Sync traits by not using RefCell and Cell in it #12

[birkenfeld]

Hi, thanks for the PR!

The problem is that when communicate can be called concurrently, replies are not guaranteed to end up where they need to go - if two threads start a request at the same time, the reader thread will just send both replies to the channel, and each calling thread will get one, but they might be the wrong ones.

It's certainly possible to make it work, but so far I haven't thought about what the minimal/best change to the architecture would look like to achieve that.

[cartercanedy]

I wrapped all of the client network IO in a mutexed block. I can see this getting more efficient if you wanted to adopt a coroutine-oriented api with primitives from async_lock

[cartercanedy]

@birkenfeld I ended up refactoring the background worker logic a bit so that the client can dispatch requests concurrently and receive their responses asynchronously

[cartercanedy]

Hey @birkenfeld just a friendly ping :)

[birkenfeld]

Thanks! This isn't forgotten, I just need a quiet time for review... Fortunately some leave is coming up during which I might have time for that.

[cartercanedy]

No problem, like I said before, feel free to suggest/make changes!

[cartercanedy]

I also had a productive conversation with bhf support about routing in general, and now I'm fairly certain that the Source::Auto variant is pretty much never valid unless you manually configure the routes on the remote (which contradicts the semantics of "auto" routing, imo). I'll create another issue with better details