fix: Property wrappers are now thread safe

[adrien-coye]

An interesting rare bug pointed me to the fact that DI resolution was thread safe but property wrappers were not.
This is fixing that. Now a class can expose a @LazyInjectService (or @InjectService), access it from any random thread concurrently and it won't cause a crash.

InjectService is made @unchecked Sendable.
LazyInjectService is now @unchecked Sendable with a GCD DispatchSemaphore as I need to express the Lazy part of it.

Reworked the PR to maintain a swift 5.8<->6.0 compatibility while maintaining thread safety.

This PR is now backward and forward compatible. Can be published as a 2.0.3

[PhilippeWeidmann]

I'm wondering if Service now needs to be Sendable this will be breaking a change ?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[adrien-coye]

@PhilippeWeidmann I made changes to be certain this is not a breaking change in pure Swift6 mode while maintaining thread safety. In 5.8 mode, it was not an issue.

[PhilippeWeidmann]

I did some tests (but not all use cases / all views) on the mail.
While I didn't see any direct performance impact I'm still not fond of potentially waiting on a semaphore on the main thread.

I think it would be better to have a new thread safe property wrapper to resolve the concurrency issues we have outside the main thread. We could also annotate @mainactor the LazyInjectService or create a new type only for the main actor.

I'm open to discussion

[adrien-coye]

Open to discuss this tomorrow @PhilippeWeidmann
We do not wait unless an unlikely call is made at the exact same time from another thread.

It is super unlikely, it exists in one place on the Drive App.
It does not append on the Mail app to my knowledge as most things are @mainActor

If we do not wait during this unlikely event, this is a bug that breaks the "thread safety contract" of this library.

I'm open to create a @mainactor property wrapper if you want to migrate Mail on it, but that is a feature that should be done separately IMO.
Also, you can refrain from using the lazyInject if you want a resolution made at the exact init of the object in the same thread.

Maybe we should put in context how long you wait, only the time needed for the resolution to be performed.
The resolution is a O(1) operation (fixed time, dictionary object for key call).
Worst case the UI waits for a resolution, plus some latency, it should not stall the UI thread, or any thread.
We rely on this resolution massively in our apps, it is not stalling our apps today.

Finally, the resolution engine already runs on a serial queue, so technically today the main thread waits already.

If what you wish for is a nice Swift6 interface that prevents issues at compile time, this is not ready or built that way and requires a near complete rewrite.

[PhilippeWeidmann]

After live review we will merge this PR as is. Property wrapper used in view bodies in Mail will be modified to not be lazy.