Opened this for discussion; not 100% sure if there would be cases where we would not want to use this. If that's the case, we could consider adding a NewSequential and WriteSet.SequentialFileWriter function / method, and keep the old ones as-is. (or a NewSequentialWriteSet)

Could use some input from our Windows-native friends on this one /cc @CharityKathure @profnandaa

Let me do a quick outline of my thoughts;

• ❓ First of all; question is if the benefits of using sequential files are worth making this change; I implemented this, based on some existing uses elsewhere, but I'm not sure exactly what's best to measure if it's relevant or if it's pre-mature optimization
• ☝️ I tried to get some input from ChatGPT to see if it could tell if it's mostly relevant for "large files" or "small files", and what kind of patterns most benefit. I think it came down to "it can be relevant for files only used once / temporarily" (which makes sense).

The reason I opened this PR was because I wanted to replace some code in docker/cli with our atomicwriter package; see docker/cli#5914

• ☝️ that code is used to save/export images, which could be large files (and possibly only written to as a temporary file)
• 👉 inside moby/moby, the code is used in quite some places, including to write the container's config / state to disk (so different pattern; would that be a "pro" or "con" for this?)
• ❓ from that perspective, would it make sense to have separate methods? (NewSequential / NewSequentialWriteSet)

In general, I'm playing with the idea to move this package to a separate module in the https://github.com/moby/sys repo (i.e., to become github.com/moby/sys/atomicwriter). The downside of using the sequential package is that this would mean we'd have a cross-module dependency; not disastrous, but sometimes makes it slightly more complicated to work with.

This PR was discussed in the maintainer call last Thursday;

• We discussed whether we should use Sequential file by default, and concluded that it won't hurt to do so by default; if it doesn't benefit, it also won't hurt for how we're using these.
• We discussed potentially moving this package to moby/sys, and maintainers were ok doing so; this will be looked at separately.

Let me bring this one in 👍