Cleanup the `Polly` and `Polly.Specs` codebase

[martintmk]

In the #1287 we enabled a full set of analyzers for these projects. Many of the rules are currently suppressed in each respective csproj file with the <NoWarn> element.

We can enable these rules one-be-one and cleanup the codebase.

[davidCett]

Hi👋I would like to help with this issue

[martincostello]

@davidCett Thanks for volunteering! Feel free to open a pull request to tackle one of the disabled warnings. I suggest you tackle one or two per pull request to prevent the diffs getting too big to easily review.

[martincostello]

💡 Tips for future contributors working on this issue:

• Only the Polly and Polly.Specs projects are still in scope for this issue. Other projects with analyzer suppressions are intentional (we've intentionally turned them off, rather than it being "let's fix it later") and represent cases where we specifically disable a rule for a project because it is not useful or code-level suppressions are too noisy (e.g. the Polly.Benchmarks project disables rules that are not compatible with BenchmarkDotNet's requirements for benchmark classes).
• Avoid fixing more than one analyzer ID in the same pull request. Unless the changes are trivial, raise a new pull request per analyzer rule - this makes code review much easier for the maintainers as otherwise you could potentially change dozens of files.
• Consider whether a specific change is useful. If fixing a specific analyzer rule impacts hundreds of files and is a subjective opinion, it may not be worth fixing and can just be left suppressed. If you're unsure, feel free to ask in a comment below before starting the work if you feel it would generate a large change.
• Do not change the public API in the case of the Polly project. If fixing an analyser rule would require a change to the public API surface (e.g. renaming a member, re-ordering arguments etc., things that require changing a PublicAPI.*.txt file), then do not make the suggested change - instead, suppress the warning(s) on a case-by-case basis with a pair of #pragma warning {disable|restore} {AnalyzerId} directives in the source file(s).
• If changes add new code to the Polly project (e.g. adding missing validation, rather than style-only changes), then ensure that test coverage is not impacted. This will require adding new unit tests.

[sukreshmanda]

For the warnings xUnit1031, it says blocking calls should not be used in a test method. The below mentioned code uses Task.WaitAll which is a blocking action.

Example :

#pragma warning disable xUnit1031 // Do not use blocking task operations in test method

Task.WaitAll([firstExecution, secondExecution], testTimeoutToExposeDeadlocks).Should().BeTrue();

#pragma warning restore xUnit1031 // Do not use blocking task operations in test method

The essence of the above lines is to check if firstExecution and secondExecution tasks finishes before the specified timeout (testTimeoutToExposeDeadlocks). I want to confirm if the below mentioned non-blocking code can be a proper replacement for the above code.

var allTasksTask = Task.WhenAll(firstExecution, secondExecution);

var completedTask = await Task.WhenAny(allTasksTask, Task.Delay(testTimeoutToExposeDeadlocks));

(completedTask == allTasksTask).Should().BeTrue();

[martincostello]

If I remember correctly, these tests are specifically testing synchronous code paths, so the suppressions should be left in place.