http::server: a multi-range request gets the whole body, because multipart/byteranges is not implemented

[xoloki]

Range is implemented for a single range (#227): 206 with Content-Range, 416
for an unsatisfiable one, If-Range with strong comparison, and files()
seeks rather than reading.

More than one range is ignored, and the client gets the whole
representation. RFC 9110 14.2 permits that explicitly -- "A server MAY ignore
the Range header field" -- and the reasoning is in decide_range:

Answering two means multipart/byteranges, a whole body format with its own
boundaries, to save a round trip for a client that could have asked twice.
The cost is not in proportion to the benefit.

What implementing it would mean

• A multipart/byteranges body: a boundary string, a part header per range
  carrying its own Content-Type and Content-Range, and a terminating
  boundary.
• Content-Type: multipart/byteranges; boundary=... on the response, which
  means the response's type is no longer the representation's type.
• A Content-Length covering the whole multipart body, which has to be
  computed before anything is written -- so for files() it is arithmetic over
  the ranges plus the part headers, not a stat.
• Overlapping and out-of-order ranges, which 14.1.2 allows and which a naive
  implementation will coalesce wrongly.

Why it is filed and not done

No client here asks for it. Media players send one range and seek again; a
resumed download sends one. The case for it is a PDF reader fetching several
objects at once, which nothing in this tree is.