Implement our own multipart/form-data serialization

[domenic]

This allows us to remove the form-data dependency, which was not very efficient, probably not very spec-compliant, and has recently been taken over by a maintainer that bloats it with dependencies.

Closes #3320.

[domenic]

Implementation report:

This was in the no-AI bucket, and I kind of felt the pain. AI definitely would have saved me some time here, but I'm not sure how significantly. It was mostly about the experience being much less pleasant without tab completion, the codebase knowledge, and AI as a replacement for Google/StackOverflow.

This involved a good deal of research into the current state of the codebase, to try to figure out what we needed to add and remove. This wasn't terrible, but could have been faster if I were able to ask the AI about things in the current codebase, and in the form-data dependency package that we were replacing.

Similarly, once I figured out that we needed to implement https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart%2Fform-data-encoding-algorithm from scratch, I started poking around the specs, and was frustrated to discover that https://www.rfc-editor.org/rfc/rfc7578 is basically useless as an implementation guide. At this point I was wishing I had AI, which could at least explain the basics of the multipart form-data format to me, and maybe get me started on an implementation.

Thankfully, I pushed a bit harder and found whatwg/html#6424, which linked to https://github.com/andreubotella/multipart-form-data, which was much better. It's a bit of a sobering thought to imagine if I had relied on AI and not found that document: that would have been a big setback.

Implementing the algorithm was somewhat mechanical, and is the same sort of task I've run into a few times during the uplift project, where I might have been able to point AI at the spec and asked it do the whole task, but I'm not sure how well it would have worked. In the end, finding the right place in the codebase to insert the new code was pretty subtle, and the final solution involved removing a lot of redundant code that we'd been keeping around to paper over the seams between jsdom and the form-data dependency. I think it's fairly unlikely AI would have come up with that elegant of a solution in the end, given what I've seen previously about how it seems to jump on the first plausible-looking avenue of attack.

I definitely made several simple coding errors during this work that would not have happened with AI tab completion. (TypeScript might have helped too, for some if not all.)

Once I was producing some form data, but not passing the tests, I had no idea whether my output was on the right track or just totally off. I had to go run the test in Firefox and compare Firefox's output, which took some effort and also the game of spot-the-difference is something an AI could do faster. I would have preferred to just ask an AI "what's wrong with this output?" and it would have figured it out quickly since multipart/form-data is a well-known format.

[jimmywarting]

kudos!

just wondering why we can't just use the built in (undici) fetch, formdata, blob, file etc.
would be a hecka lot easier, no?