fix(eventhubs): enforce the AMQP link maximum on single event sends

[Johnathan W (j7nw4r)]

Summary

ProducerClient::send_event and ProducerClient::send_message now reject a message larger than the maximum the sender link reports, and they do not transfer it. The batch path already enforced that limit, so the two publish paths now agree.

Motivation

A live run against a Standard namespace read the link maximum as 1048576 bytes, and a 2 MiB event sent with send_event returned Ok(()) and reached the partition. The AMQP library is the cause: fe2o3-amqp treats max-message-size as a split boundary and fragments an oversized payload across transfer frames instead of refusing it, and its newest release still does, so the client must make the check itself. A caller that publishes one event at a time got no size protection from the client, and the .NET client refuses the same publication.

Changes

• Added the public ErrorKind::MessageSizeExceeded { requested, max_allowed } variant. ErrorKind is #[non_exhaustive], so the addition is additive. ErrorKind::InvalidBatchSize was not reused, because it reports a batch size option the caller asked for and its text does not describe an oversized message. The .NET client keeps the two faults apart for the same reason.
• Added ProducerClient::check_message_size, the one crate-internal function that holds the comparison.
• send_message reads the maximum from RecoverableSender::max_message_size, the same lookup create_batch uses, and checks the encoded message before the transfer. send_event reaches the check through send_message.
• A link that reports no maximum is not checked, because AMQP 1.0 section 2.7.3 gives an unset or zero max-message-size the meaning "no limit". This differs on purpose from create_batch, which treats a missing maximum as an error.
• The boundary is inclusive, so a message of exactly the maximum is still sent.
• The two paths share the limit source and the comparison, not the arithmetic. The batch path adds an envelope, pads each message, and compares a running total against a cap the caller can lower, and a single send has none of those.
• Added the CHANGELOG entries and the rustdoc for both public methods.

Test plan

• Four offline unit tests drive check_message_size for a size above the maximum, exactly at it, below it, and with no reported maximum. They failed to compile before the fix, and each one fails on its own under a matching mutation of the comparison.
• One live test, send_event_rejects_message_above_link_maximum, sends a 2 MiB event through both public methods, asserts the error kind, then sends a normal event on the same client to show the link is still up. The live run is PENDING, because one shared namespace served eight concurrent runs; a serialized live pass follows.
• cargo test -p azure_messaging_eventhubs --all-features --lib: 148 passed, 0 failed, 14 ignored.
• RUSTFLAGS=-Dwarnings cargo test --no-run --package azure_messaging_eventhubs: exit 0.
• cargo fmt --check, cargo clippy --all-features --all-targets --no-deps -- -Dwarnings, and RUSTDOCFLAGS=-Dwarnings cargo doc --no-deps --all-features: all exit 0.

Closes #5101

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
3 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[minghuaw]

This is likely a bug in fe2o3, opened an issue, but the fix will likely need a breaking release