Add CancellationToken.CombineWith extension methods

[AArnott]

Using this can help reduce allocations in frequented code that links (for example) its own CancellationToken that tracks disposal with a caller-provided CancellationToken.

Allocations are avoided by only creating the linked CancellationTokenSource when there are actually multiple cancelable CancellationTokens (as opposed to the popular CancellationToken.None).

[sharwell]

💡 readonly struct

💡 Consider making this a top-level type. While it's vital users dispose of it properly, it seems reasonable that it would be stored for disposing at a later point.

[AArnott]

readonly struct

Done.

Consider making this a top-level type.

I think I see your point. It's not particularly the use case I'm going for though. Everywhere I've seen where multiple CancellationToken instances must be combined it's within a method and therefore only ever required as a local where var would suffice.
The cost of another top-level type is of course that it adds to completion lists and it's not a top-level scenario to engage with this type directly.
So I'm torn.

[sharwell]

💡 Consider placing this in a new type CancellationTokenExtensions

[AArnott]

Good idea.

[sharwell]

💭 The alternative here is:

if (original.IsCancellationRequested || !other.CanBeCanceled)
{
  return new CombinedCancellationToken(original);
}

if (other.IsCancellationRequested || !original.CanBeCanceled)
{
  return new CombinedCancellationToken(other);
}

// This is the most expensive path to take since it involves allocating memory and requiring disposal.
// Before this point we've checked every condition that would allow us to avoid it.
return new CombinedCancellationToken(CancellationTokenSource.CreateLinkedTokenSource(original, other));

Not sure if the pair of these is simpler than the ternary at the end, but it seems to make the method "appear" less complex (shorter by ~5 lines with one less block).

[AArnott]

Sure, I can go with that.