[Feature Request] Create more consistent, accessible and configurable stat reporting

[InspectorCaracal]

Strap in, this one's going to be a long one.

Is your feature request related to a problem? Please describe.

At the moment, Evennia supports two very similar, yet completely disconnected mechanisms for game-stat reporting.

MSSP

MSSP is defined here. It's a fairly standardized MUD-centric telnet option for making various information about your game available - genre, uptime, codebase, etc. MSSP allows other services to request the current status and info of your game... as long as those services are using telnet.

Evennia comes with a default MSSP table built into its MSSP implementation, but also allows for customizing and augmenting the information being sent via a module-level dictionary.

MSSP is also antiquated and solely used by a shrinking number of MUD-listing sites.

Evennia Games Index

The Evennia Games Index is an official game-listing site that uses JSON data from subscribing games to create informational listings. It's also integrated directly into core evennia, but rather than allowing other services to make requests to your game, it runs as a polling service within your game and actively sends updates to the game listing site.

Evennia comes with a built-in tool to generate a new file for this game index, which generates a file that contains, again, a module-level dictionary.

Also, while the EGI is very nice and I like having it there, it's also pretty much unmaintained.

Why this status quo kind of sucks

These two modules and their module-level dictionaries are completely independent of each other. Theoretically one could set up one's own game to reference the same module-level dictionary for both services, but as they currently have entirely separate methods of generating certain information and validating the provided information, it could easily just mess both of them up. So we're left with maintaining two separate sources of information about our game if we want to use them both.

Furthermore, this current two-part implementation of Obtaining Game Info is completely lacking in anything to support a more modern-web friendly method of requesting that information. You use MSSP over telnet, or you scrape the EGI, or you go to the game devs and say "hey can I have your game info please thanks". There's nothing that will provide even a basic JSON manifest.

Since the current game-info solutions are so tightly tied to their respective use-cases, adding in, say, a new toggleable-but-provided-by-default view under yourdomain/info, or putting it into the REST API as yourdomain/api/info, or any other info-request solution that's compatible with the modern web, would thus require creating and maintaining info for a third, completely separate system. This means that even that third option - which more realistically might be "hey devs, can you install this code into your game so I can get status reports from it?" - is (aside from lbr sounding very sus) going to be annoying and require more maintenance from the devs. Nobody wants that.

Describe the solution you'd like

The ideal solution requires three things:

1. Refactor the current MSSP and EGI code to reference a single shared source of truth, the location of which is defined in a single setting.
   • The EGI should still have its own ENABLE toggle setting.
   • MSSP could and likely should have an ENABLE toggle setting as well.
2. Ensure that whatever validation is necessary for the MSSP and EGI rendering methods is implemented individually in a way that will simply ignore invalid fields. (Based on my cursory review, this should largely work as-is.)
3. Add a new view (with its own ENABLE toggle setting) or API endpoint (which would be included with the REST API toggle setting) which will provide the same information from the same source as a standard JSON response.

Describe alternatives you've considered

The only alternative solution is to create a third entirely separate system for requesting game info, which would thus need to be separately maintained as well and exacerbate the existing problem. (Or, you know, DNI the idea.)