Add HTTP/1.1 content delay for server chaos testing

[masaori335]

Add a delay key inside a content node which pauses between writing a message's headers and writing its body. This lets a replay file simulate an origin that starts a response and then stalls, which exercises proxy timeout and partial-response handling that no existing replay construct could reach.

The delay is inserted in Session::write(HttpHeader) immediately before the write_body call, so it covers HTTP/1.1 both in the clear and over TLS. HTTP/2 is unaffected because H2Session overrides that method; those messages already express the same behavior with a delay on their DATA frame, so combining a content delay with a frames node is rejected with a diagnostic pointing at the DATA frame alternative.

A shutdown during the delay abandons the body write, matching how the existing transaction delay behaves. A peer which departs during the delay is the expected outcome when the delay is used to trigger a proxy timeout, so the resulting body write failure is reported through the errata and annotated with the delay as its likely cause, without affecting the process exit code.

The AuTest duration verifier only matched the plural form of the client timing line, so its regex now also accepts the singular form which a single transaction replay emits.

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

[bneradt]

To fix the format, there's a tools/format.sh

---

I like this feature a lot, but from a usability standpoint, I would like content:delay to:

• apply across h2 and h3 as well (we don't support h3 on the server side, so this isn't applicalbe to h3 response bodies, of course).
• apply to request bodies for all protocols (I think your PR already applies to request bodies for h1, which is good).
• apply to 100-continue requests sending the body after the 100 response is received

We don't need to suport that in this PR if you don't want, but before cutting a release with this, it would be good for the project to support all of the above. And I can help with some of the development if you like. Or you can do it. Either way. Just let me know how you would like to proceed.

Thank you so much for the contribution!