Adds bytesRead() method to RequestContext

[daanjanschouten]

This change exposes bytesRead() on RequestContext for use in application code. The implementation tracks bytes at the I/O layer via an Undertow conduit wrapper, providing accurate measurements with minimal overhead.

The byte count is stored using the existing attachment mechanism, in line with how the existing UNVERIFIED_JWT and FAILURE attachments are used. For requests with empty bodies, Undertow may not create an input conduit, in which case bytesRead() returns 0.

This change is a better version of #2771 because it exposes significantly less API surface area.

After this PR

==COMMIT_MSG==
Adds bytesRead() method to RequestContext
==COMMIT_MSG==

[changelog-app]

Generate changelog in changelog/@unreleased

Type (Select exactly one)

• Feature (Adding new functionality)
• Improvement (Improving existing functionality)
• Fix (Fixing an issue with existing functionality)
• Break (Creating a new major version by breaking public APIs)
• Deprecation (Removing functionality in a non-breaking way)
• Migration (Automatically moving data/functionality to a new system)

Description

Adds bytesRead() method to RequestContext

Check the box to generate changelog(s)

• Generate changelog entry

[changelog-app]

✅ Successfully generated changelog entry!

Need to regenerate?

Simply interact with the changelog bot comment again to regenerate these entries.

---

📋Changelog Preview

✨ Features

• Adds bytesRead() method to RequestContext (#2776)

[aldexis]

That's not actually true and if you search for implementations, you'll see that there are a few other places that implement it https://pl.ntr/2Aq. They seem to be fake/empty contexts, but these appear in prod code https://pl.ntr/2As.

I don't remember off the top of my head the exact impact on the binary compatibility of adding an unused method to an interface, but I could see this break class validation when loading a class that implements an interface but not all the methods

[daanjanschouten]

Good find, thank you. The RequestContext interface does specify that it should only be implemented within conjure-java-undertow-runtime, so unfortunate in that regard.

I've modified the interface method to instead provide a default, to ensure existing implementations don't break. The only remaining risk now is that some implementation was additionally implementing another interface that has the same default method, but that seems extremely unlikely, and would be caught at compile time. None of the existing implementations from your link suffer from this.

[aldexis]

Note that being caught at compilation does not mean we can't hit this at runtime in prod, since ABI break issues typically happen due to diamond transitive dependencies. I agree with you that this doesn't seem like it would happen here though

[daanjanschouten]

Closing this PR out for now after today's discussion, may revive at a later point in time.