Add API allowing to disable retries for a given list of HTTP methods

[iliar-turdushev]

The PR introduces an API that allows to disable automatic retries for

1. a given list of HTTP methods;
2. a list of unsafe/non-readonly HTTP methods: POST, PATCH, PUT, DELETE, and CONNECT.

Here is the approved API #5248 (comment).

Closes #5248.

[iliar-turdushev]

Alternatively, we can return HttpRetryStrategyOptions to make this and other extension-methods configuring HttpRetryStrategyOptions "chainable". Honestly, at the moment I don't see a necessity for that, but probably in future we'll want to introduce more API and make them fluent.

I would personally leave the API as-is returning void. What do you think?

[RussKie]

This is more a question for the API Review Board. Here are the general rules: https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-rules.md.

I think that changing the return type from void to T should be an acceptable change in the future, but I may be wrong... @terrajobst @bartonjs what's your take on this?

[bartonjs]

I think that changing the return type from void to T should be an acceptable change in the future, but I may be wrong...

Methods in .NET are named for their full signature, including the declared return type. So any callers from before you change it will get a MissingMethodException if they run against a library after you change it.

If you want to change it between previews that will annoy your users, but you can do it (with a breaking change notice). Once you abandon the preview label it is what it is forever (you'd have to leave this one as-is and make some other overload that happens to return the data, but clearly can't have the same calling signature).

[RussKie]

Thank you, @bartonjs, for clarifications.

[bartonjs]

FWIW, in that breaking change guidelines doc, it says it's OK to change the return value, but that it's not OK to change the return type.

Returning a value of a more derived type for a property, field, return or out value

Note, again, that the static type cannot change. e.g. it is OK to return a string instance where an object was returned previously, but it is not OK to change the return type from object to string.

_{Emphasis mine}

[iliar-turdushev]

We need this condition to satisfy the compiler because RequestMessage is nullable HttpRequestMesssage?. I don't think in reality it could be null. Alternatively, we can throw an exception here, but I think it is better not to fail here, but rather let the original ShouldHandle predicate to take a decision whether to do retries or not.