Federation authenticated media endpoints have invalid multipart response

<!-- All bug reports must provide the following background information Text between <!-- and --​> marks will be invisible in the report. IF YOUR ISSUE IS CONSIDERED A SECURITY VULNERABILITY THEN PLEASE STOP AND DO NOT POST IT AS A GITHUB ISSUE! Please report the issue responsibly by disclosing in private by email to security@matrix.org instead. For more details, please see: https://www.matrix.org/security-disclosure-policy/ --> ### Background information <!-- Please include versions of all software when known e.g database versions, docker versions, client versions --> - **Dendrite version or git SHA**: `0.13.7+7a4ef24` - **SQLite3 or Postgres?**: unknown (not my server) - **Running in Docker?**: unknown - **`go version`**: unknown - **Client used (if applicable)**: Grapevine `b4fecbc51719a33d09be1e76d55ae0eec11fb71a` (over federation API) ### Description The [multipart spec](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) states that every encapsulation boundary in the body should be preceded by a CRLF. Instead, dendrite's response to the federation auth media download endpoint has the `--` of the first boundary starting directly at the beginning of the body, with no CRLF. Ruma expects a preceding CRLF [here](https://github.com/ruma/ruma/blob/14d7415f0d80aadf425c2384c0f348d1c03527c8/crates/ruma-federation-api/src/authenticated_media.rs#L172) when parsing the response. As a result, homeserver implementations using ruma are unable to fetch media from dendrite servers over the authed media endpoints. This affects grapevine, and likely also affects conduwuit although I have not tested it. <details> <summary>relevant text from RFC 1341</summary> > Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain). > NOTE: The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. > The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line -- that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. This is indeed how such entities should be composed. A tolerant mail reading program, however, may interpret a body of type multipart that begins with an encapsulation line NOT initiated by a CRLF as also being an encapsulation boundary, but a compliant mail sending program must not generate such entities. </details> ### Steps to reproduce - issue a `/_matrix/federation/v1/media/download/:mediaid` request to a dendrite server - inspect the response body. Every multipart boundary should start with a CRLF. Instead, the first boundary begins immediately.