Support "multipart/mixed" and "multipart/related"

Besides multipart/form-data, there are two other multipart media types in use:

• multipart/mixed, as defined in RFC 1341, and used in OData Batch Processing
• multipart/related, as defined in RFC 2387, and used in Google Cloud Multipart Upload.

These have different properties than multipart/form-data, for instance in that they do not require a Content-Dispostion header for each part.

Furthermore, it seems that OData relies on nested multipart/mixed structures, where the outer batch part can contain a changeset that is in itself a multipart consisting of changes.

Not having done a full investigation, it appears that there are a number of issues with our current WebFlux multipart support that prevents us from fully supporting multipart/mixed and multipart/related:

• The DefaultPartHttpMessageReader is not capable of reading nested multipart messages.
• The MultipartHttpMessageWriter and PartEventHttpMessageWriter are not capable of writing nested multipart messages, except in a raw form.
• The Part and PartEvent interfaces expose a name property that reflects the Content-Disposition name, but which only makes sense in multipart/form-data.
• The MultipartHttpMessageWriter and PartEventHttpMessageWriter write a Content-Disposition header, which it only needed in multipart/form-data.

This issue was created to gather all research done on multipart/mixed and multipart/related done so far, and to see how much interest there is in the community for Spring Framework to fully support these multipart types.

Start by reviewing DefaultPartHttpMessageReader, MultipartHttpMessageWriter, PartEventHttpMessageWriter, Part, and PartEvent, then compare their current behavior with RFC 1341, RFC 2387, and the linked OData and Google Cloud multipart examples. Document the required reader and writer changes for nested multipart/mixed and multipart/related support and define acceptance criteria before implementation.