Fix Jetty 12 HTTP server metrics collection without virtual threads

[Arunodoy18]

After upgrading to Dropwizard 5 (which uses Jetty 12), HTTP server metrics were not being collected or exposed correctly when virtual threads were disabled (enableVirtualThreads=false). The metrics appeared correctly only when virtual threads were enabled.

Root Cause:
The Jetty12ServerInstrumentation was ending spans in two places:

1. In onMethodExit when the handle() method completed
2. In HttpStream callbacks (succeeded/failed) for request completion

When virtual threads were disabled, handle() often completed synchronously BEFORE the HttpStream callbacks fired. This caused the span to end prematurely in onMethodExit, and metrics were not properly captured. The HttpStream callbacks would then try to end an already-ended span.

When virtual threads were enabled, the asynchronous nature ensured callbacks fired before method exit, so metrics were captured correctly.

Solution:

1. Modified Jetty12ServerInstrumentation.HandlerAdvice.end() to NOT end the span in onMethodExit (except when there's an exception). The span is now ended exclusively by the HttpStream completion callbacks.

2. Added AtomicBoolean in Jetty12Helper.start() to ensure the span ends exactly once, preventing double-ending issues regardless of callback order.

This ensures HTTP metrics (request counts, latency, body size, per-endpoint and per-status-code metrics) are collected correctly whether virtual threads are enabled or disabled.

Fixes the issue where Dropwizard 5 applications with enableVirtualThreads=false would not report HTTP server metrics.

[jaydeluca]

can you please include tests for this change