AMQP changes for C++ Claim Based Security - also fixed session close issue that affected reliability

[LarryOsterman]

This pull request introduces several important changes to the azure_core_amqp and azure_messaging_eventhubs SDKs. The most significant updates involve adding lifetime parameters to various structs and implementations to ensure proper borrowing and memory management. Additionally, there are some minor improvements and refactorings to enhance code clarity and error handling.

Lifetime Parameter Additions:

• sdk/core/azure_core_amqp/src/cbs.rs: Added lifetime parameter 'a to the CbsImplementation type alias and AmqpClaimsBasedSecurity struct to ensure proper borrowing of AmqpSession. [1] [2]
• sdk/core/azure_core_amqp/src/fe2o3/cbs.rs: Added lifetime parameter 'a to Fe2o3ClaimsBasedSecurity struct and its methods to ensure proper borrowing of AmqpSession.
• sdk/core/azure_core_amqp/src/noop.rs: Added lifetime parameter 'a and a PhantomData field to NoopAmqpClaimsBasedSecurity struct to ensure proper borrowing of AmqpSession. [1] [2] [3]

Refactorings and Improvements:

• sdk/core/azure_core_amqp/src/fe2o3/connection.rs: Simplified error handling and removed unnecessary unwrap calls by using if let instead of ok_or_else. [1] [2]
• sdk/eventhubs/azure_messaging_eventhubs/src/consumer/mod.rs and sdk/eventhubs/azure_messaging_eventhubs/src/producer/mod.rs: Updated AmqpClaimsBasedSecurity::new calls to pass a reference to AmqpSession instead of taking ownership. [1] [2]

[heaths]

The generated summary covers the what, but that's obvious in a fairly small PR. I'm curious as to the why. Is it because the AmqpSession was being copied? Was the Arc<> causing delays?

[LarryOsterman]

The generated summary covers the what, but that's obvious in a fairly small PR. I'm curious as to the why. Is it because the AmqpSession was being copied? Was the Arc<> causing delays?

The problem was that when the types underlying the session were copied, somehow the underlying fe2o3::session::SessionHandle got dropped. That shouldn't have been possible, but the traces were unambiguous: The underlying AMQP layer felt it was necessary to drop the session handle. Possibly that was because I didn't clone the session properly, I honestly don't know.

However, while I was trying to figure out why the sessionhandle was dropped, I realized that the session lifetime was always going to be longer than the CBS lifetime, so instead of taking a reference to the underlying Arc, I could just take a reference to the session. And once I switched from taking a reference to the Arc<Mutex<SessionHandle>> to taking a reference to the Session, the problem went away.