fix: don't warn on routine client-disconnect write/flush errors (#2589)
## Summary
While investigating https://github.com/php/frankenphp/issues/2588, found
two related logging bugs around client disconnects.
`go_sapi_flush` logged every `ResponseController.Flush()` error under
the same message:
> the current responseWriter is not a flusher, if you are not using a
custom build, please report this issue
That message is only accurate for `http.ErrNotSupported`. A plain
disconnect/write error (e.g. an aborted HTTP/2 stream) got mislabeled
the same way, misleading and able to mask the real cause when triaging
issues shaped like #2588.
Also reconsidered the log level. `go_ub_write`'s equivalent "write
error" was logged at warn, so the new "flush error" branch was first
matched to it. But a client disconnecting mid-response is routine, and
both writes and flushes happen in a loop, so a single request can log
this dozens or hundreds of times, one per write/flush call after the
disconnect. Not warn-worthy.
Checked how the two other Caddy-family projects here handle this same
class of error:
- Caddy's reverse proxy streaming (`streaming.go`): "backConn write
failed", "response flush", "streaming error" - all logged at debug.
- Mercure's SSE hub (`subscribe.go`): "Failed to write comment"
(per-write, in a loop) and "Connection closed by the client" are debug;
only one-off lifecycle events like "Subscriber disconnected" are info.
Matched that convention:
- `go_ub_write`'s "write error" -> debug (was warn).
- `go_sapi_flush`'s "flush error" -> debug (routine disconnect),
correctly separated from "not a flusher".
- `go_sapi_flush`'s "not a flusher" -> stays warn (real
misconfiguration, not a per-request occurrence).
This only fixes logging, not the segfault. I was not able to reproduce
the crash reported in #2588 (see comment on the issue).
## Test plan
- `go build ./...`
- `go vet ./...`
- `go test -run "TestConnectionAbort|TestLog" ./...`