[THRIFT-5871] Add message / container size checking for Rust

[mhlakhani]

Bring the Rust implementation somewhat up to par with the other implementations. I tried 4-5 different ways to get the "perfect" check but since trait specialization is not yet stable, I was not able to arrive at a solution I'm happy with (code was either ugly, or had runtime overhead).

So for now, we avoid full message size tracking / more precise limit checking, but this is a strong step in the right direction.

Apologies for the large PR - but most of it is boilerplate (configuration) or semi-exhaustive tests.

• Did you create an Apache Jira ticket? (Request account here, not required for trivial changes)
• If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
• Did you squash your changes to a single commit? (not required, but preferred)
• Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
• If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

[mhlakhani]

I'll look at the cross test failures -- I can understand the ones with rust involved, the others are a bit surprising.

the go-rs ones look potentially unrelated to this PR:

[2025-07-18T22:13:29Z INFO  test_client] *** EXPECTED: Ok(00010203-0405-0607-0809-0a0b0c0d0e0f)
[2025-07-18T22:13:29Z INFO  test_client] *** ACTUAL  : Err(ApplicationError { kind: ProtocolError, message: "*thrifttest.ThriftTestTestUuidArgs field 0 read error: don't know what type: 15" })
[2025-07-18T22:13:29Z INFO  test_client] cross-test client failed with error ApplicationError { kind: ProtocolError, message: "*thrifttest.ThriftTestTestUuidArgs field 0 read error: don't know what type: 15" }

[Jens-G]

Wild guess: the type 15 is that uuid?

[mhlakhani]

@Jens-G that's likely (and will try to chase this down next week when I have more time) -- but I am trying to understand if this failure is pre-existing on trunk, so I will try to reproduce this locally without my changes, first

[mhlakhani]

@Jens-G I confirmed I can reproduce the same failures (for go,rs) on the master branch so it's unlikely to be affected by my PR. Do we have a tracking ticket for that? I can look into that at some point, separately, but perhaps doesn't make sense to block this PR on that fix?

[mhlakhani]

Submitted a separate PR for the cross tests - they were broken on master: #3179

[Jens-G]

+1 LGTM (not tested)