Add concurrency annotations to fix strict compilation warnings

[rebello95]

This contains fixes for warnings that appear by enabling Swift strict concurrency in the Xcode 15 beta:

swiftSettings: [.unsafeFlags(["-Xfrontend", "-strict-concurrency=complete"])]

[rebello95]

@eseay this is ready for your review

[eseay]

@rebello95 everything looks great! Honestly, despite the shear number of changes, the changes themselves are relatively straightforward.

One suggestion -

It may be helpful to clients implementing the library to provide a bit of guidance around how we are addressing making closures @Sendable in situations where you're wanting to update some kind of external state, but you need to do so in a thread-safe 'sendable' manner.

I know we want to keep Locked as internal as we can, but perhaps we can point to it as an example of how one can implement such a type themselves as well as an example of how we're using it in unit tests.

[rebello95]

Thanks for the review, @eseay.

It may be helpful to clients implementing the library to provide a bit of guidance around how we are addressing making closures @sendable in situations where you're wanting to update some kind of external state, but you need to do so in a thread-safe 'sendable' manner.

I know we want to keep Locked as internal as we can, but perhaps we can point to it as an example of how one can implement such a type themselves as well as an example of how we're using it in unit tests.

Hmm, I don't think this is a pattern that's unique to Connect though (I believe it's pretty common when using closures with Sendable) - where do you think this should live if we were to add it?

[eseay]

Thanks for the review, @eseay.

It may be helpful to clients implementing the library to provide a bit of guidance around how we are addressing making closures @sendable in situations where you're wanting to update some kind of external state, but you need to do so in a thread-safe 'sendable' manner.
I know we want to keep Locked as internal as we can, but perhaps we can point to it as an example of how one can implement such a type themselves as well as an example of how we're using it in unit tests.

Hmm, I don't think this is a pattern that's unique to Connect though (I believe it's pretty common when using closures with Sendable) - where do you think this should live if we were to add it?

You're definitely right in that it's not unique to Connect. I was more just thinking that it could be helpful for someone integrating Connect into an existing project where widespread familiarity with Sendable may not be the case. I personally had to do a little bit of digging to figure out the right solution for something like this when it came up in some of my other code.

Maybe we could add another example in the README that reflects one of the unit tests you've written where we're employing Locked, and we could just put some code comments around it that explain why the lock is necessary. And in that case, I'd say don't use Locked; use plain NSLock so as not to leak that further into the public API.

[rebello95]

Ah okay, that makes sense @eseay. I think that should probably live here, though: https://connectrpc.com/docs/swift/testing#using-generated-mocks

Is that okay with you? If so I can put a PR up for that. Would also appreciate another look at this PR - I pushed some changes per our offline conversation about allowing mocks to be open.

[eseay]

@rebello95 LGTM!