[up-for-grabs] FEATURE: Add Noop policy

A NoopPolicy would not influence execution of the delegate/func passed to Execute() (etc) in any way: it would simply execute it.

Uses/benefits:

• For a feature-toggle to temporarily suspend use of the normal Polly policies (such as suggested in #182)
• Sometimes, in a unit-test, you may want to test the functionality of some SUT without a Polly Policy it contains coming into play. Passing the policy into the SUT by DI can facilitate this: passing in a NoopPolicy particularly.

(Current workround: passing in Retry(0) achieves no-op, but this is not widely documented and not as immediately intuitive as NoopPolicy might be.)

(great up-for-grabs item for anyone interested in getting familiar with the Polly codebase: state interest here and I can provide further pointers if helpful!)

[reisenberger]

Can’t see a shorter way of getting to Retry(0) 😉

My thought on this had been that we go the step further and create the NoOpPolicy type. Semantically richer than retry-masking-noop, for probably <100 sloc.

Also, a NoOpPolicy doesn’t need a .Handle<>() clause (/doesn’t make sense), so we’d probably (like TimeoutPolicy) want to configure by static method directly on Policy.

This one ‘up-for-grabs’ again, for anyone who wants to get into the Polly codebase!
(I heard on other channels that the original contrib is unavailable at mo)

[reisenberger]

Closed through #214