Report query timing from the servers to size the client's update window

[domoritz]

The coordinator now keeps a window of selection updates in flight per client (#1208). The right window size depends on how much of a query's round trip is network versus server time, and on whether the server is queueing. The client cannot tell today.

Proposal

Servers report two numbers per query: database time and total time from receiving the request to writing the response. The difference is queue wait on a busy connection.

• Carry them in Arrow schema metadata (db_ms, total_ms). The same path works over HTTP and the socket, flechette exposes schema metadata, and no CORS setting is needed. Exec responses return an empty Arrow stream with the same metadata, since feat!: remove json query type from connectors #1172 removed the JSON acknowledgment.
• Attach the metadata at send time, not when caching, or cache hits report the original query time.
• The connector hands the numbers to the query manager, which keeps a moving average of network time per connector and database time per client.

Use

• Network time equals round trip minus total time. Raise the update window while the server is idle during the round trip, so roughly round trip divided by database time, capped. A serial server with a long round trip benefits too.
• Queue time above zero means the window is already too large. This is what keeps the window at one when queries take longer than the round trip.
• Database time tells which charts are cheap enough to pipeline and which are the slow ones a round should not wait for.

Notes

• Python already measures total time for its log line; Go and Rust do not measure yet.