Add unsafe_close to ServiceClient

[VegetarianOrc]

What was changed

• Wrap bridge's ClientRef.retry_client in an option
• Add some helper methods to ease retrieving the value from the Option<Client> that returns a PyErr in the case it doesn't exist.
• Update references to retry_client with the new helper method.
• Expose new ClientRef.drop_client() method in Python via ServiceClient.unsafe_close()

Why?

As described in #1202, some advanced users need to control the timing of closing TCP connections.

Checklist

1. Closes [Feature Request] Advanced, unsafe ability to close the client #1202

2. How was this tested:

   Unit test was added to query connections owned by the process and verify changes in connection count.

3. Any docs updates needed?

[cretz]

I don't think this is predictable enough. The goal is to guarantee that when unsafe_close returns, the socket is no longer connected. But in this case, if a call was being made or the client is held in some other way by some other Core aspect, the connection will remain.

I think we may have to provide an "unsafe close" on the Rust side that does a predictable channel drop and confirms it is the only one using the channel. Hopefully that's not too hard to do, I have not looked into it. This may require putting the channel in a non-cloneable wrapper and having an Arc of that. Or maybe you have to get access to the non-cloneable underneath part. Unsure.

[Sushisource]

I'm not 100% sure if this is sufficient. Clients are Clone themselves, and share the underlying connection. It's entirely possible that on the Core side we might clone the client somewhere and then dropping the client ref won't actually seal the deal.

That said, there's also no readily available way to actually close the underlying connections Core side either. So, we might have to just attach a small caveat here in the docstrings or something.