Add full PaperMC auto-update support

[SuperChewie]

Add full PaperMC auto-update support

Summary

This PR adds full lifecycle support for PaperMC. This allows worlds configured with mscs-server-type=papermc to automatically track, download, and verify PaperMC builds via the PaperMC v3 Downloads API. It also reorganizes the version JSON cache into a dedicated versions/ subdirectory and ships five new unit test files.

Note: Claude was used to support the development of these changes.

---

Motivation

PaperMC is one of the most widely used Minecraft server implementations, offering significant performance improvements over vanilla. Previously, MSCS users who wanted PaperMC had to manually manage JAR downloads and set mscs-server-url by hand — losing out on the automatic update flow that vanilla worlds enjoy. This change closes that gap by wiring PaperMC into the same mscs update / mscs force-update lifecycle used by vanilla, with no extra steps required after initial configuration.

Additionally, the version manifest JSON was previously stored directly in /opt/mscs/, alongside world directories and defaults files. Collecting all cached version JSON into a versions/ subfolder makes the layout cleaner and provides a natural home for the new PaperMC cache files.

---

Before

• mscs-server-type=papermc was not a recognised value; users had to manually set mscs-server-url, mscs-server-jar, and re-set them on every PaperMC release.
• mscs update / mscs force-update only knew how to handle vanilla Minecraft; running either on a PaperMC world did nothing useful.
• No build channel selection was available; users couldn't opt into BETA or ALPHA builds.
• version_manifest.json was stored directly in /opt/mscs/.
• No unit tests existed for world lifecycle, config operations, server version resolution, or PaperMC functions.

After

• Setting mscs-server-type=papermc in mscs.properties fully enables the automatic update flow:
  • mscs update fetches paper_project.json (list of available MC versions and builds) and the per-version paper_builds_VERSION.json, then compares the SHA256 of the installed JAR against the latest build. If a newer build is available the JAR is replaced automatically — no force-update required for build bumps within the same MC version.
  • mscs force-update wipes all PaperMC cache files (paper_project.json and paper_builds_*.json) and re-downloads everything from scratch.
  • Version and JAR defaults are derived automatically; no manual mscs-server-url or mscs-server-jar configuration is needed.
• A new mscs-paper-channel property (per-world) and mscs-default-paper-channel (global default) control which build channel is targeted: STABLE (default), BETA, or ALPHA. getCurrentPaperVersion skips MC versions that have no build in the configured channel.
• getServerCurrentVersion, a new dispatch function, replaces direct calls to getCurrentMinecraftVersion in getServerVersion, getServerJar, getServerLocation, and getServerURL, so all server-type-specific logic flows through a single case-based switch.
• Post-download integrity verification uses SHA256 for PaperMC (matching what the API provides) and retains SHA1 for vanilla.
• All version cache JSON files now live under /opt/mscs/versions/. A migration script (update.d/20-versions-subfolder) moves any existing version_manifest.json (and its .bak) into the new location on make update.
• Five new test files cover world lifecycle, config operations, vanilla server version resolution, PaperMC functions (getCurrentPaperVersion, getPaperServerURL, getPaperServerChecksum), and the getServerVersion dispatch path — all using file fixtures with no network access.

[SuperChewie]

Should be merged along with this documentation update. MinecraftServerControl/MinecraftServerControl.github.io#18

[SuperChewie]

@sandain this new feature is ready for review. I have tested the upgrade via make update from the last couple of versions. I have also tested out a fresh install. The testing was done on Ubuntu.

[sandain]

Hi @SuperChewie. Thanks for your work on this, it is something that I have thought about doing in the past but never got around to. I'll need to spend some more time reviewing the changes before I accept the PR and I'm rather busy at the moment, but I will get around to it. If anyone else has the chance to test these changes in the meantime, please give us a report on your thoughts.

[SuperChewie]

@sandain Its a lot of code changes so I get needing time to review. My goal was to setup a framework for auto updates so that additional server types could be supported in future features. In fact I'm using this to build one for Forge.

As a contributor, what would be helpful to comment as far as test results? I get doing QA yourself, just trying to make it easier.

Hopefully the unit tests for the additional functions will help improve confidence in future code work.