Implement new retry types in the Event Hub producer

[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

• On construction, instantiate a new EventHubsRetryPolicy based on the retry options provided as part of the client options.

• Expose the retry policy as its abstract base type in a property, which can be set by callers.

• Update infrastructure through the transport and compatibility levels to make use of the new retry policy types.

Out of Scope

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

• Updating other 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.

• Tests and related infrastructure have been updated.