Fix bridge client lifetime in spin context

[ssnover]

I was looking to tackle the issue where the Client::stubborn_spin function would hold onto a Client forever and it turned into a rabbit hole. I ended up moving all of the members to a ClientInner struct which is co-owned through Arc<RwLock<T>> by the spin context and by all Clients.

In the nominal case, the lock is only being accessed as a reader because all of the members themselves are only used immutably (at least directly). This should mean that all accesses are very fast. However, if it disconnects from the bridge, the spin context takes a write lock which will be exclusive and allows it to overwrite the transport.

This is work in progress right now. One remaining task is there needs to be protection against starving of the write lock since it's totally possible for a user who relies on the stubborn reconnect to spam Client methods and for the write lock to be unobtainable.

[Carter12s]

The diff for this one is a mess, but in principle I like the changes. I might name things slightly differently like ClientHandle and Client vs. Client and ClientInner.

With how messed up the diff is pretty hard to tell what state this is really in, but let me know when its not WIP and I'll take a closer look.

[ssnover]

Main remaining item I want to address is prevent soft deadlocks by users repeatedly retrying methods while waiting for the reconnect and the reconnect being starved of the write lock.

[Carter12s]

Main remaining item I want to address is prevent soft deadlocks by users repeatedly retrying methods while waiting for the reconnect and the reconnect being starved of the write lock.

This is an awesome thing to have an integration test around. I think beyond features, the most important thing we can do to make this crate have value is make it bulletproof so when we see edge cases that might exist in the API that rust can't directly guard against we should strive to cover those with tests.

[ssnover]

This is no longer work in progress and should be ready for a full review!

[Carter12s]

Did you intend for this to Merge into master?

[ssnover]

Oh yeah, I targeted at the other branch because that branch was still in review. It looks like we need to close branches when they're merged since we have a lot of stale branches.

[ssnover]

The diff is much cleaner now actually. That's a little unexpected.