Introduce concept of enforced atomic operations (fix #193151)

[rebornix]

The only two file system providers being passed to FileUserDataProvider is either the disk one or the in memory one. The former already supports IFileSystemProviderWithOpenReadWriteCloseCapability thus in this PR we added the capability to the in memory file system provider

[bpasero]

LGTM except one code style issue.

I leave it up to @sandy081 to comment on the impact of this change. I think the idea of this provider was to explicitly enforce atomic writes on the level of the file system provider for all user data files (except backups). With your change, we now rely on the file service to use writeFile for this to happen. But writeFile is used only in specific conditions, for example when the file is small (3 * 64kb I believe) or when a file is changed not through an editor that has a ITextSnapshot but programmatically where the entire buffer is passed in (which I believe is most often the case with user data).

[sandy081]

or when a file is changed not through an editor that has a ITextSnapshot but programmatically where the entire buffer is passed in (which I believe is most often the case with user data).

@bpasero Is it also true if programmatic save goes through ITextFileService.save ?

vscode/src/vs/workbench/services/textfile/common/textfiles.ts

Line 60 in 0b08c9a

save(resource: URI, options?: ITextFileSaveOptions): Promise<URI | undefined>;

[bpasero]

@sandy081 no. But I think a better solution is to stop overriding the file system provider and do what I had suggested in #193151 (comment)

[sandy081]

In this case, I would not suggest this change. It is important to have atomic write for user data like settings and extensions.

[bpasero]

This is ready for review.

[sandy081]

Good change. I liked it.

[sandy081]

Good change. I liked it.