Refactor retry policy implementation and remove operation timeouts

[jsquire]

Summary

The current implementation from the first preview mirrored the approach to retry exposed by the track one client. After discussion, a new approach was recommended by the architecture board, which separates out the options to define a retry from the policy that implements it. Since the majority case can be served by specifying options for retries, there is no need to require the actual policy to be set.

Each set of options currently allows for an operation-specific timeout to be applied, which is used by the underlying communications between the client and service. It was recommend that this concept be included as part of the retry policy and redefined as a "per-try" timeout.

Scope of Work

• Create a set of retry options, which includes a per-try timeout setting, that can be used to configure a retry policy.

• Remove the concept of specifying a retry policy on client options; make use of the retry options instead.

• Remove the concept of specifying an "operation timeout" on client options; make use of the "per-try" timeout for the active retry policy instead.

• Add a base retry policy (abstract) which can be implemented by developers with advanced needs.

• Implement a concrete EventHubsRetryPolicy that is capable of being configured by the retry options.

Out of Scope

• Changes to any references within the TrackOneClient code; that will remain as-is.

• Updating clients options to consume the new types; this will be covered under a dedicated workstream.

Success Criteria

• The new approach to retries and associated types have been created.

• The track two code performs appropriate translations to the track one concepts.