New rule proposal: Propagate cancellation tokens

[sharwell]

This diagnostic would be reported when CancellationToken.None is explicitly provided in a call, but another cancellation token is available in the current context (see #36 and #32 for comments describing the current context).

The code fix for this would replace the use of CancellationToken.None with the "best" cancellation token as described in the code fix for #36.

[vweijsters]

👍

[tmaczynski]

I will implement this analysis.

[tmaczynski]

I think that this analysis should be also triggered if default(CancellationToken) is provided in a method call as it's equal to CancellationToken.None.

[sharwell]

@tmaczynski Yes, that's correct.

[tmaczynski]

I'm hesitating if local fields of type CancellationToken should be considered in this diagnostic or not (current description suggests that they should not), any thought on that?

Also, I think that all CancellationToken parameters, local variables (and possibly, fields) should be suggested by a codefix provider, not only the "best" (innermost) one.

[sharwell]

@tmaczynski I'm not sure for fields. I could see it going either way.

[sharwell]

@tmaczynski Oh, maybe just treat this as a potential context object?