Support Server-Timing header

[lidel]

TODO

This feature may be useful enough to be promoted upstream:

• support timing info from caboose support in feat: add Server-Timing headers #71.
• add gateway-related timing here
• evaluate usefullness
• decision to move middleware to upstream boxo/gateway library

---

What and why

Ref. https://www.w3.org/TR/server-timing/

TLDR: we want to leverage UI in modern browsers to give more info about where Gateway request was spent:

Source: https://ma.ttias.be/server-timings-chrome-devtools/

How

TBD, there is a library at https://github.com/mitchellh/go-server-timing + slack thread

Middleware for injecting the server timing struct into the request Context and writing the Server-Timing header.

there is slight risk middleware will not be compatible with how we do subdomains, but that is tbd.
we can give it a try in bifrost-gateway and see how it goes.

on the surface level it sounds sensible,

• only normal header, no Trailers (http.headers.Trailer - reading trailers not supported by Fetch API mdn/browser-compat-data#14703)
• context thing does not require another API rewrite, caboose can set whatever it wants, we would return it
• if we find this useful, boxo/gateway could add own metrics and/or we could make this part of Gateway spec

[lidel]

@hacdias as a PoC, we could give it a try by exposing a single value (e.g. one passet to i.getMetric here to test things end-to-end.

@willscott @aschmahmann
FYI I am adding more meaningful metrics and tracing spans in ipfs/boxo#245, we might be able to leverage ipfsBackendWithMetrics for exposing timing details per IPFSBackend api call via Server-Timing header.

[lidel]

basic support landed in #71, added remaining TODO section to the top of this issue

what gateway-related timing info should we return? Amount each IPFSBackend call took?