Add API to provide cache and data directories

[modmuss50]

This is very work in progress, I look forward to getting some input on this:

The goal with this PR is to strongly define all of the locations on the filesystem where a mod should read/write files. Currently the only defined directory is ./config. This is useful for a few reasons, its easier for the developer as they do not need to implement platform specific code, better for the user as all of the mods files are located togeather and allows for new technology such as the fabric-sandbox.

This PR adds 4 new directories that mods can use to store data:

• getCacheDir() returns an instance specific directory for mods to store data that should be cached across runs. Fabric loader uses this to cache the remapped jars. The contents of this directory can be regenerated if deleted.
• getGlobalCacheDir() returns a location that is shared across all instances of Fabric Loader (regardless of Launcher or Game). This can be used to cache files across multiple instances, an example of this might be downloading addional files required for your mod. As above contents of this directory can be regenerated if deleted.
• getDataDir() returns an instance specific directory for mods to store user generated data. This directory should be included in mod packs. An example of this may be client side map data (when playing on an MP server), schematics, blueprints. Basically anything that isnt a human editable file should go here (otherwise it lives in /config).
• getGlobalDataDir()is similar to the global cache dir, but may be included in computer backups or synced across computer (E.G Active directory on windows). This directory may be used to store files such as private keys to encrypt secrets, the secrets themselves, or just user configuration that should persist to all instances of the game.

It is not expected that a user will ever manualy edit files in these locations. A sandbox may grant full access to all of these directories, without any isolation. Thus untrusted code must not be executed from these locations.

A mod ideally should not be saving any files outside of these locations + /config and the save directory.

On a server the global directories are stored within the servers directory, and are not shared between instances.

I am very much open to feedback on these locations, we should try our best to ensure that they are good, as changing them later will be difficult to do without introducing breaking changes.

	Windows	MacOS	Linux	Include in Mod Pack
Data	./fabric/modid/	./fabric/modid/	./fabric/modid/	✅
Cache	./cache/modid/	./cache/modid/	./cache/modid/	⛔️
Global Data	%AppData%/net.fabricmc.loader/modid/	~/Library/Application Support/net.fabricmc.loader/modid/	~/.config/net.fabricmc.loader/modid/	⛔️
Global Cache	%LocalAppData%/net.fabricmc.loader/modid/	~/Library/Caches/net.fabricmc.loader/modid/	~/.cache/net.fabricmc.loader/modid/	⛔️
Global Data (Server)	./fabric-global/modid/	./fabric-global/modid/	./fabric-global/modid/	⛔️
Global Cache (Server)	./cache-global/modid/	./cache-global/modid/	./cache-global/modid/	⛔️

Extra care needs to be taken to test this on a range of linux platforms/launchers, especially those using Docker, Flatpacks and Snaps. This can be tested easily by copying this code in a mod.

[zenfyrdev]

Since the cache dirs are not meant to be included in modpacks and not to be interacted with by players, maybe they should be hidden?

[isXander]

I'd be interested as to your opinion on making these directories' names less fabric specific. A ton of mods nowadays are multi-loader, and a global Fabric directory isn't that global for a mod that supports Fabric and NeoForge.

[Julienraptor02]

I'd be interested as to your opinion on making these directories' names less fabric specific. A ton of mods nowadays are multi-loader, and a global Fabric directory isn't that global for a mod that supports Fabric and NeoForge.

indeed, imo ./data/modid for data would make more sense
as for global data, i see the point of it, but i'm not sure to like it that much ?
i'm not sure the "(regardless of Launcher or Game)" part makes sense
regardless of launcher, why not yet questionnable, but of game ?
also when we have launchers that allow us to make separated instances and can be fully self-contained, having stuff completely outside of it seems weird ?
i was thinking for the global directories, to simply reuse the vanilla .minecraft and global-data/cache
but that only makes sense if it's not regardless of game ?
also the point bring up above about mods being multi-loader
i wonder if the best way wouldn't be to have launchers set the global dirs via a launch arguments
that way smth like Prism which is entirely self-contained in a folder could simply set the global dir to be similar like minecraft's assets which are global for the launcher and not per instance
as for the server the global directories kinda serve no point as they aren't shared by default which is interesting for smth supposed to be global so i really don't see the point of it

TL;DR imo the local cache and data make entirely sense but data should be ./data/modid and not ./fabric/modid
for the global dirs, i'm unsure how they could be set up to make sense as a user i'm not sure i would be able to find oh actually there's a magic directory completely outside of my launchers with clean isolated instances that does some shared magic
maybe this should be added in 2 waves, one to add cache and data dir and one to add global dirs

[Qendolin]

As mentioned a few months ago on discord (link), it might be a good idea to split this PR up, because the global directories are a lot more complicated to implement.
I'm in favor of using a loader agnostic directory name, it would be great for cross loader compatibility. Fabric API itself uses a directory called "data", see GameOptionsMixin. Using that name is simple and idiomatic.

Also, I just asked, and NeoForge also doesn't have a standard.

[BasiqueEvangelist]

The Linux paths for global data and global cache should follow the XDG Base Directories Specification (ideally XDG_STATE_HOME for global data and XDG_CACHE_HOME for cache, and their respective fallbacks if the variables aren't present). This would make it work with Flatpak (which points the variables to directories under ~/.var/app/{appid}/ and blocks access to the typical locations) and esoteric setups with non-standard state and cache dirs.