Refactor connection locks

[simolus3]

The existing implementation around connect() and disconnect() has a bit of an odd control flow. I couldn't find any likely race conditions, but this still cleans up the implementation a bit to be easier to reason about. In particular, some of the things this addresses:

1. While we acquire a mutex for connect(), we were not doing this for disconnect(). So if we call connect() and then immediately call disconnect(), it's possible that disconnect() does nothing because the AbortController has not yet been set.
2. reconnect() doesn't actually check if we still need to connect, so a disconnect() call followed by an error on the isolate could cause another connect() that is not stopped.
3. We set an onExit port when spawning the isolate, but there's a separate Isolate.current.addOnExitListener command in the background isolate. The two trigger different behavior, this has now been cleaned up.
4. The Isolate.spawn call is not awaited, meaning that another connect() call could begin before the earlier one started setting up the sync client. I don't think this causes any issues, but it's still better to restrict concurrency around connect().

This also adds a lot of internal assertions to ensure we're not calling the internal connect methods concurrently. I'm still not sure how the problem with duplicate sync streams was caused though, the existing implementation should have guarded against that too.

[stevensJourney]

Happy with the changes from my side.