[Event Hubs] Allow users to configure retry options in receiveBatch

[ramya-rao-a]

• Allow users to configure retry options in the receiveBatch() request as described in [Event Hubs] Review retry logic against the guidelines #2661 (comment)
• Ensure the concerns in [Event Hub] Consider not reconnecting for batching receiver #1331 are addressed

Using retries for the creation of receiver link is covered in #2835

[ramya-rao-a]

Thoughts after offline discussions:

Current state:

• In case of errors on the AMQP receiver link or AMQP receiver session, receiveBatch returns rejected promise with the error. Subsequent calls to receiveBatch will create new receiver link and receive messages
• In case of connection errors, the receiveBatch operation times out and the returned promise resolves to the events that were collected till that point. Subsequent calls to recieveBatch will fail until the network is back

Proposal to add retry options to receiveBatch() such that

• In the first case above, we can create new receiver link without bothering the user in case of retryable errors.
  • Downside: The user might have time sensitive application and added a modest maxTimeWait option for receiveBatch operation. Us retrying behind the scenes will only hold up the operation that the user is awaiting on. Maybe, dont retry by default unless user specifies retry options? Or have such users provide options so as to not retry at all.
• For the second case, the initial link creation can use the retry policy provided here.

Implementation option:

• Use the RetryConfig directly in the receiveBatch with the operation being bReceiver.receive
• detached() is not called for batching receiver

[ramya-rao-a]

As per the API proposal in #2718 (comment), we will now have a createReceiver() method on the Event Hub Client that returns a receiver. It is on this method that we will be allowing retry options rather than individual operations.

Therefore, closing this issue in favor of #3184