add nixos support!

[C0D3-M4513R]

What's new

• Add NixOs Support (fixes Recaf on NixOs #739, addesses Package request: recaf NixOS/nixpkgs#267124 )
• Add NixOs CI
• Add Gradle Verification Metadata (can be kept automatically up-to-date with Introduce Renovate #776 )

What's fixed

• Recaf crashes when opening and when trying to open a file dialoug.

Once Nixos-unstable is released as a proper release branch, we should use that.
(gradle8.8 is not in any other nixos release channel).
A new nixos release will take a bit longer, hence the decision to just use nixos-unstable.

[Col-E]

Is this XML blob all the hashes of the dependencies we pull in?

[C0D3-M4513R]

yeah. It's necessary for how I build using nixos currently (ref. https://github.com/raphiz/buildGradleApplication)
It can be mostly auto-generated by using gradle: ./gradlew --refresh-dependencies --write-verification-metadata sha256 build

[Col-E]

The changes to some gradle settings I'm fine with, but there's a lot of stuff in here that I don't believe should be in this repository.

1. I'm unfamiliar with the Nix ecosystem, and I do not want to have to maintain unfamiliar integrations in this project
2. I am not privy to opening up first-class support for any one specific platform. This project should just offer the basis for our own release system, and any artifacts needed for third party platforms to maintain their own such as how AUR/Brew have operated in the past with Recaf releases.
   • To elaborate, enforcement of reproducible builds and easy to access artifacts in a sensible pattern is 👍 with me. But that's the only level of contribution I am comfortable giving to platforms looking to make their own release variants of Recaf.
3. Nitpicky, but the root directory is already kinda messy, this adds 5 new files

[C0D3-M4513R]

I'm unfamiliar with the Nix ecosystem, and I do not want to have to maintain unfamiliar integrations in this project

I can understand that decision, but due to no gradle verification metadata being present, it's almost impossible to package using nixos (you have to know & download all dependencies beforehand, as you have no internet connection when building) [I might be able to look at more of nixos and figure out what they do, but this approach works just fine for me for now].
I have also moved all repositories into the settings.gradle, which is apparently also a requirement/constraint of https://github.com/raphiz/buildGradleApplication.

If this repository had a gradle verification metadata setup, I might be able to package this by adding patches to move the repositories into the settings.gradle and then fetch the source & build. This would require more pr's to https://github.com/raphiz/buildGradleApplication (specifically I can't specify a source, nor patches). This has the included challenge, that the new repo has no clue when there is a new commit to dev4, making ci nearly impossible (save for polling regularly for updates).

I am not privy to opening up first-class support for any one specific platform. This project should just offer the basis for our own release system, and any artifacts needed for third party platforms to maintain their own such as how AUR/Brew have operated in the past with Recaf releases.

I am unsure of how to contribute this to nixos (outside of the first point), since I am using https://github.com/raphiz/buildGradleApplication, which is not present in nixos. This is why I made a pr to here, instead of nixos.

Additionally I feel that it is unfair to compare NixOs to the AUR.
The aur's build process is basically just ./gradlew build.
NixOs's build process is essentially this entire pr.
This packaging pr does these things:

1. Download all dependencies from the verification metadata and the specified repositories (currently in the package.nix. It's a todo in buildGradleApplication) into a pseudo maven repository.
2. Internet is disabled (I have no choice over that) and a grade build is started.
3. The packaging replaces all configured repositories during gradle's initialisation with a build script with the pseudo maven repository
4. The build continues as usual
5. The output is wrapped in a binary wrapper, which sets the Java Home and fixes the File dialogue.

The binary wrapper additionally references files, which are produced during the build.
(NixOs has a concept of a store, where everything resides. It is populated with dependencies, the build outputs and the wrappers during the build process.)

Nitpicky, but the root directory is already kinda messy, this adds 5 new files

settings-gradle.lockfile is kinda a gradle file, which might or might not need to be in version control.
The other's I might be able to move to a subfolder.

Ultimately I made this, so I can get recaf working easily on nixos (eliminating the need to reboot into windows, make an edit, reboot into nix, try the edit, find out the edit doesn't work and repeat).