BUG/MINOR: mux-h2: also emit the HPACK Dynamic Table Size Update before trailers

BUG/MINOR: mux-h2: also emit the HPACK Dynamic Table Size Update before trailers

Commit 39a0a1e12 ("MEDIUM: h2/hpack: emit a Dynamic Table Size Update
after settings change") made the mux emit an HPACK Dynamic Table Size
Update at the beginning of the first header block following a change of
the peer's SETTINGS_HEADER_TABLE_SIZE (RFC7541#4.2). The previous commit
did the same for request HEADERS, but h2s_make_trailers() still never
emits it, on any side, so that if the first header block following the
change is a trailers block, a strict decoder will report a
COMPRESSION_ERROR and kill the connection.

It's quite unlikely to happen to be honest, because:
  - on the frontend, the client sends the SETTINGS frame before headers
    and has no real reason to change it afterwards ;
  - on the backend, it could theoretically happen but only on a large
    POST that receives a SETTINGS frame after the first HEADERS frame and
    acks it before the trailers HEADERS frame; it's not as if trailers to
    backends were that common anyway.

The update is now inserted before the encoded fields of the trailers when
at least one field is present. Otherwise an empty DATA frame is sent
instead of a HEADERS frame, and the update is left for the next header
block. The flags are only updated once the frame is committed, as in the
other functions.

This was verified on the backend with a server sending its SETTINGS frame
with a lower header table size after receiving a request's HEADERS frame:
the request's trailers now start with the update, which was not the case
before. The frontend case was only verified by code analysis, it uses the
same code.

Like previous patch, this could be backported to all stable versions, but
preferably only if found to be necessary. Let's just start with 3.3 and 3.4
only.