[Evolution] Add-ons v3

[3vorp]

As Faithful has grown a lot over the past few years, the old add-on system is really starting to show a lot of problems. I think doing a new addon system would be a good idea at this stage (migrating all the old addons over in the process)

Features:

• Use two separate collections for storing user-facing and staged addons, so when an add-on gets an update it doesn't get delisted from the site until approval. ([Feature] Add "draft" stage for add-ons #69 )
  • The staging collection could be much more lax typing-wise, so draft addons could be made with partial fields.
  • If an add-on gets an update denied, the old version is left up with no changes.
  • A user can archive or private an add-on for maintenance without having to outright delete it.
  • A user-facing addon could be either approved normally or also alternatively archived if it contains old content, which would still be visible ([Feature] Legacy page for Faithful Extras that don't comply with the new ruleset Website#72)
  • One big pain point could be handling image updates, since only one version is actually stored on our server physically. This would probably require Firestorm changes if we wanted to store both versions ([Feature] Add more file methods TheRolfFR/firestorm-db#34).
• Proper tagging system (just steal PMC or Modrinth's tagging system) [Feature] Improve add-on tagging #56
• Support all packs properly, and be able to add new packs/have them automatically update using the pack API ([Feature] Explicitly support Classic Faithful with add-ons #55 )
• Generalize the OptiFine field into a dependencies field, allowing users to specify both the dependency and the reason it's required (e.g. polytone, optifine) Generalize OptiFine field into a dependencies section and add a field to describe why each dependency is needed #24
• Add a creation date field (why is this not a thing already)
• Keep a record of every addon status change instead of only showing the most recent one, and allow users to attach changelogs to each add-on update (this could either be a completely separate collection or be a list contained within the addon file).
  • A possible schema could be like { changelog: string, status: AddonStatus, approval: { reason: string, author: string } }, also taking care of that whole aspect