Consider changing Obsolete text to clarify when callbacks need to take an additional CancellationToken

[idg10]

As reported in #2283, there's a potential trap for people migrating from System.Linq.Async to .NET 10's System.Linq.AsyncEnumerable. The old library offered XxxAwait forms in which you could supply async callbacks that don't take cancellation tokens, and it also offered XxxAwaitWithCancellation versions in which the callbacks do take cancellation tokens.

But the new .NET 10 library only supports the second usage model.

So as well as replacing calls to, say, SelectAwait with Select (because System.Linq.AsyncEnumerable uses more modern naming conventions) it is also necessary to modify the callback to accept the additional CancellationToken argument.

While I have fairly low confidence that everyone will read the Obsolete attribute message in enough detail to spot this, I think we should at least try: the message for these methods should make it clear that you need to change the callback signature.

[julealgon]

You may also want to mention the change from Task<T> to ValueTask<T>. This might catch people off guard if they are passing method groups into the Select method directly or calling their existing methods in the lambda.

[idg10]

You may also want to mention the change from Task to ValueTask.

Which methods did you have in mind? I thought Ix.NET's System.Linq.Async was using ValueTask<T> for all of its async callbacks.

[julealgon]

You may also want to mention the change from Task to ValueTask.

Which methods did you have in mind? I thought Ix.NET's System.Linq.Async was using ValueTask<T> for all of its async callbacks.

Ah, nevermind. I was making an assumption based on the sample in #2283 where Task.FromResult was being used that the Ix must've had Task-based overloads. I see now that's not the case so please disregard the above.