Bug: maxLatencyWriter panics on hijacked connections with OpenTelemetry enabled

Root Cause Analysis

The crash is caused by a nil pointer dereference when the Gateway attempts to asynchronously flush an HTTP response on a hijacked connection.

1. Hijacked Connection: When an API uses WebSockets, Server-Sent Events (SSE), or custom streaming, the connection is hijacked. Once hijacked, the standard Go HTTP server stops managing the connection buffer.
2. Asynchronous Flush: Tyk Gateway uses a maxLatencyWriter which spawns a background goroutine (delayedFlush) to periodically flush the response writer. For WebSockets and SSE, the flush interval is hardcoded to -1 (flush immediately).
3. The Crash: When OpenTelemetry is enabled, the response writer is wrapped by otelhttp and httpsnoop. The delayedFlush goroutine triggers a flush that propagates through this middleware chain down to the standard net/http and bufio packages. Because the connection has already been hijacked, the underlying buffer is invalid (nil), resulting in a segmentation violation (SIGSEGV) when bufio.Flush is called.

Steps to Reproduce

1. Enable OpenTelemetry in tyk.conf (opentelemetry.traces.enabled = true).
2. Create an API that proxies to a WebSocket backend.
3. Send a WebSocket upgrade request to the Gateway.
4. The Gateway will panic with a nil pointer dereference in maxLatencyWriter.delayedFlush.

A test case has been added in gateway/reproduce_panic_test.go that reproduces this exact scenario.

Impact

Gateway crashes in production when OpenTelemetry is enabled and WebSocket/SSE traffic is processed.

Workaround

Disable OpenTelemetry globally until the bug is fixed. There is no API-level override to disable OpenTelemetry for specific APIs.