Add a timing for response body times

[deweerdt]

This is useful for comparing HTTP/2 and HTTP/3 performances since headers are subject to client prioritization in the latter but not in the former. That makes the existing response_time not as useful to reflect server performance

[kazuho]

This is useful for comparing HTTP/2 and HTTP/3 performances since headers are subject to client prioritization in the latter but not in the former.

I think the code might fine, but I'm not sure if it matches the rationale being described.

The PR sets response_body_start_at in the do_send callback, which means that response_body_time will be measuring the duration between when the first byte of the response body was provided by the generator. That is a metric representing the backend behavior, and therefore it is unlikely that this metric would reflect the differences between the frontend protocols.

If we want to observe when the headers or the first chunk of body is written to the TCP or QUIC stack, I think we need to add code to different locations.

For the first byte of the body, the moment of start would be when:

• H2: emit_writereq_of_openref callback is invoked the first time for each stream, or
• H3: on_send_emit callback that contains something other than headers (we might need to add a flag indicating that to the sendvec) is invoked.

Regarding the monent of ending, I think timestamps.response_end_at correctly reflects when the last chunk is sent (for the first time, in case of QUIC).