[Service Bus] Review retry policy configurations

[ramya0820]

In issues #1717 and #1718, the sender client was observed to have failed after attempting a set number of pre-configured retries.

The objective of this issue is to deep-dive and document the available retry policies. Review these with team and subsequently make any feature changes if required.

[ramya-rao-a]

Below is the list of all main operations and their retry policies.

Operations	Class	Retry policy
AMQP Connection creation when the client is created	ConnectionContext	None. And this is fine. No real connection to the service is made until the first request is sent to Service Bus to either send/receive or use any of the $management operations
AMQP Link creation	MessageSender, BatchingReceiver, StreamingReceiver, MessageSession, ManagementClient, CbsClient	No retries for link creation, timeout is 60 seconds. Link creation is preceded by claim negotiations which use retryAttempts: 3, delayBetweenRetries: 15, timeoutForOperation: 10
AMQP Link recovery which occurs when a retryable error occurs on the link or the connection	MessageSender, BatchingReceiver, StreamingReceiver	retryAttempts: 150, delayBetweenRetries: 15, timeoutForOperation: 60 ------- When any of the these links are recovered, claims are negotiated which brings up the CBS link which is why we don't attempt to recover it explicitly. ------ Subsequent management operations will create new $management links which is why we don't attempt to recover it explicitly
NegotiateClaim	CbsClient	retryAttempts: 3, delayBetweenRetries: 15, timeoutForOperation: 10
Operations on the $management link	ManagementClient	retryAttempts: 3, delayBetweenRetries: 15, timeoutForOperation: 10. Except renew lock operations that use 5 retryAttempts, 1 second delayBetweenRetries and 5 second timeoutForOperation
send & sendBatch	MessageSender	retryAttempts: 3, delayBetweenRetries: 5 + jitter , timeoutForOperation: 60
Receive in a batch	BatchingReceiver, MessageSession	None. If link goes down in the middle of receiving, error is thrown to the user but link is not recovered
Receive in a stream	StreamingReceiver, MessageSession	None. If link goes down in the middle of receiving due to a retryable error, the link is recovered and we resume receiving messages
Settling a message	ServiceBusMessage	For deferred messages, we use the managementClient, so default retry policy (retryAttempts: 3, delayBetweenRetries: 15, timeoutForOperation: 10) there. For other messages, no retry policy

Event Hubs shares the same polcies as above (just remove MessageSession, ServiceBusMessage and renewLock concepts from the above table)

We will be using #2661 to review these policies against the guidelines and propose further changes.

[ramya-rao-a]

cc @AlexGhiondea