Update the amqp layer to inspect the inner exception for am amqp error code

[abhipsaMisra]

When link detaches are initiated by the amqp library on service side, the initiated operation is cancelled ungracefully. This results in an OperationCancelledException being thrown. The actual amqp error is present as an inner exception, though.

Since we've not been inspecting these inner exceptions for an amqp error code, this inspection can now be done in three stages:

• If exception thrown is OperationCancelledException and inner amqp error code is AmqpErrorCode.MessageSizeExceeded -> throw a MessageTooLargeException.

  • Previously - OperationCancelledException was thrown. It is a transient exception which was retried. This is a bug.
  • Now - MessageTooLargeException will be thrown. It is a terminal exception.
    This is technically a breaking change since previously customers would be receiving an OperationCancelledException but now they'd be receiving a MessageTooLargeException. However, behavior wise, the client wouldn't ever succeed previously, nor would it succeed now. Additionally, previously it would retry needlessly, while now it would fail-fast.

• If exception thrown is OperationCancelledException and inner exception is an AmqpException -> throw the exception based on inner exception.

  • Previously - OperationCancelledException was thrown. It is a transient exception which was retried. This could be the correct behavior for some scenarios while incorrect for others.
  • Now - Depending on the inner AmqpExeception the operation will be retried.
    This is a wider breaking change since previously customers would be receiving an OperationCancelledException but now they'd be receiving an exception depending on what the inner exception is.
    • Inner exception is not AmqpExeception -> sdk retries, no behavior change.
    • Inner exception is AmqpExeception and is transient -> sdk retries, no behavior change.
    • Inner exception is AmqpExeception and is terminal -> sdk will not retry. This would have always failed, however previously customers would have received an OperationCancelledException while now they'd be receiving a different exception based on the inner exception.

• For all non AmqpException exceptions, if inner exception is an AmqpException -> throw the exception based on inner exception.

  • Previously - whatever exception was caught would have been retried or rethrown.
  • Now - Depending on the inner AmqpExeception the operation will be retried.
    Ideally we should have done this from the beginning, but doing this now can potentially have the most breaking change effect. Based on how many scenarios actually have the exception nested in an inner exception, all those cases might now throw a different exception. Even though I think the end result will be desirable, i.e. the sdk will retry based more information that is provided to it; the extent of change in behavior might be too large.

This PR implements option (2), where I think the cost-return is a bit more balanced (not specific to the one message size exceeded scenario).

Fix for #2055

[abhipsaMisra]

@barustum FYI

[abhipsaMisra]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).