Poster Network: Add API that returns all groups, all types for PN Prefab

[itsitrio]

From Tap, one of the maintainers of the Unity Prefab, we should have a way to future-proof the poster network from any additional functionality growth. Tap suggested that we can return a JSON document that describes the available options and parameters, as well as any constraints (i.e. if a PID is defined, don't let the other redundant options like group and type be set) that the URL query requires.

Sample pseudo-JSON structure

[
  {
    "title": "Group",
    "type": "single",
    "query": "group",
    "options": [
      { "id": "waterwolf", "name": "WaterWolf" },
      { "id": "iwait", "name":"i.W.a.I.T." }
    ]
  },
  {
    "title": "Nickname",
    "type": "text",
    "query": "nickname"
  },
  {
    "title": "Poster ID",
    "type": "digits",
    "query": "pid"
  }
]

Maybe add a primary and mutators thing or something, or some kind of general logic thing. Maybe a top level "mode" and then a "display-if" tag on some, idk. Schema needs to be decided. But I'll leave that to y'all since you seem to know what you want, and then can review and implement the schema.

Please work CLOSELY with Tap regarding the poster network Unity Prefab to bring it up to speed with the poster network as it currently stands. This was an oversight on my part when I started coming up with ideas for the network, and I'd like to help correct course.

[TapGhoul]

Hihi, just looping myself in.

[TapGhoul]

As a note: please do not make any work on this implementation-wise, I will likely tell you to rip it out and start over if you do. We are understanding scope and scheming up a schema. I need to sign off on this before anything server-side can be implemented, I don't want to go through this issue twice in a row.

[TapGhoul]

Some Q&A:

Q: Do we plan to allow for multiple of the same filter at any point?
A: ID pre-empts all other filters, if you specify it, it just shows that one poster, full stop.

Q:: Are nicknames at all limited in charset or length?
A: All other filters are "chainable", though there's no plan to have them match multiple, i.e. you provide one type, one group, etc. but not currently multiples.

Q: Do we ever plan to modify what filters exist?
A: Nickname doesn't replace ID, it's just another indexing strategy to avoid worlds hard-coding in auto-increment IDs for posters that may change hands (though groups and in-place editing largely mitigates this).

Q: Are there any filters that don't work with others (other than nickname or pid which take priority)?
A: The other changes relate exclusively to the web UI and to how we shuffle posters requested in quick succession and have nothing to do with the prefab or resulting posters.

Worth noting also, the type and group filters are DB tables for ease of updating, so if you wanted to do the JSON API response thing from the GH issue, we can do that and just populate it with the current table contents.
It's also CF-cacheable so not a huge deal. It's not expected that the fields will change often at all, except to add new groups/types.

Groups are admin-powered, one-to-one/zero for posters (can have a group or none), one-to-many with users (users can be in multiple groups) but the actual groups table defining that is admin maintained, and types are also admin-maintained, just a select for users.
tl;dr it's not user editable, so it can be cached and doesn't need a manual refresh in the UI.

[TapGhoul]

UI mockup (excalidraw scene embedded)

[TapGhoul]

Repo at https://github.com/WaterWolfDev/PosterLoader