Add support for System.Threading.Lock

[JakenVeina]

Feature request

Please describe the feature.

Is there any interest in new operators for directly supporting System.Threading.Lock objects, where locks are used? E.G.

public static IObservable<T> Synchronize<T>(
    this    IObservable<T>  source,
            Lock            gate);

in addition to

public static IObservable<T> Synchronize<T>(
    this    IObservable<T>  source,
            object          gate);

Given that anyone wanting this operator, or similar ones, would have to implement it from scratch, rather than through composition of existing operators, that System.Threading.Lock is now considered a threading primitive, and that it would not produce any compatibility issues, it seems like a good candidate for support in the core library,

Which next library version (i.e., patch, minor or major)?

As a non-breaking new feature, this could be introduced in the next minor version.

What are the platform(s), environment(s) and related component version(s)?

System.Threading.Lock is available .NET 9+.

As I understand, System.Reactive does not currently produce target-specific artifacts above .NET 6? If so, build targeting config would need to be adjusted to add .NET 9+ artifacts.

How commonly is this feature needed (one project, several projects, company-wide, global)?

Currently, DynamicData is using a custom version of the Synchronize operator, internally, for .NET 9+ targets.

I'll be happy to provide a PR for this feature, if deemed appropriate.

[idg10]

An argument in favour of this that occurs to me is that today, if you use the existing Synchronize operator on a Lock, it will compile but it will do the wrong thing, because internally Rx will use exactly the same lock (or equivalent) mechanism as it does on any other object passed to Synchronize. That's clearly bad.

Fortunately, you do get a compiler diagnostic: an analyzer built into the .NET SDK detects this and reports CS9216 so you will at least be told that it's not going to do what you probably hoped.

So I think we should do this.

For now I've earmarked this for Rx v7.0 and not v6.1 because I wasn't planning to add a new .NET 9.0 target to the 6.x releases. However, if this issue gets enough upvotes before we manage to release 7.0, I would reconsider.