fix: corrects and stabilizes finagle instrumentation for http

[dmarkwat]

Instruments finagle-http/twitter-util with more rigor than the previous iteration. Chiefly:

• more complete instrumentation of Promise state machine (with inspiration from Kamon)
• instrumentation of the FuturePool edge case which otel executors instrumentation can be blind to
• correct chaining of netty http messages to finagle requests across various async boundaries in finagle code paths
• cleanup of previous iterations which were broken in practice but not under test (note: use of different "offload" pools addresses this)

A note on the adjustment/removal/addition of instrumentations: introduction of FuturePool as the "offloader" -- or really any use of FuturePool within the service -- should have been done originally to ensure thread boundaries were crossed and the implementation was sufficiently flexed. Since it wasn't, once a FuturePool was introduced to the previous iteration's tests, the tests broke -- both here in isolation (however thorough) and in practical code applications. The addition of different implementations based on the different threading models (unbounded pool, immediate pool, none defined) is to ensure all different modes are flexed from here on out (Parameterized tests don't work on BeforeAll methods, where the server construction occurs).

[dmarkwat]

Client tests need addressing. Server was the central focus in issue debugging and evaluation. Will mark as ready once complete.

[dmarkwat]

Tests are passing, including indy modules. This is now ready for review.

[dmarkwat]

Ran some IRL cases, and while I didn't uncover anything concrete, I did notice some edge cases related to scheduling and evaluating the Promise state machine's outcomes that could leave users open to polluted ThreadLocal Contexts. That and a gap in the H2 bridge has now been addressed.

[trask]

thanks @dmarkwat! AI code review incoming...

The big-picture restructuring (per-Promise-K virtual field, per-FuturePool/respond/transform wrapping, netty→finagle bridging through Request.ctx(), and the offloaded vs. immediate test variants) all looks reasonable. A few correctness and javaagent-hygiene issues, mostly around null/NPE handling on hot paths and a couple of throw new IllegalArgumentException(...) calls in advice helper code that violate the "javaagent code must never throw" rule (they're suppressed inside advice, but the one inside channelRead is invoked by netty itself, not by advice, so it is not suppressed and would propagate to the application).

[dmarkwat]

@trask , my pleasure -- it was a challenging project, happy to contribute whatever I can! I think I've addressed all the comments and rebased.

[dmarkwat]

@trask All comments should be addressed. LMK if there's anything you'd prefer I do with the ContextStorageCloser printing. I found it net helpful when sifting through the leaky storage issues I was experiencing.

[trask]

Last AI-review round:

[dmarkwat]

@trask addressed comments and rebased

[trask]

Thanks!

[dmarkwat]

@trask done 👍 !

[otelbot]

Thank you for your contribution @dmarkwat! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey.