Created "state" module to distinguish between database and state

[kbarkevich]

For a while, database.py has been our catch-all for storing non-Session server data. However, there is a classification to be made: permanent data (that needs to be stored long-term database for preservation between server restarts) and non-permanent data (that can/should be wiped between server restarts). Permanent data currently only includes the online_support_code->*capcom_id association; these associations will be stored in a proper database once one is created, and should as such be kept in the database.py module. However, every other currently implemented storage mechanism (the server list, the gates list, the players lists, etc) are not going to be stored in the long-term database. These are volatile and represent the current state of the server, and will be wiped clear upon restart.

Furthermore, once each server process is responsible for a single Server instance, the distinction between state and database will be much more important. Each Server will then be responsible for its own list of Players, Gates, Citys, etc.

Other long-term data that will be stored in the database.py module in the future will include the capcom_id -> *friend_capcom_id associations for the friends list, the capcom_id -> *blocked_capcom_id for the block list, and so on.

This PR creates a new module, state.py, and moves all data that will not be stored in the actual database to that module.

[sepalani]

I suggest that you switch this PR to a draft. Renaming or moving functions from one module to another doesn't solve the problem you describe, nor provide direct benefits. This PR doesn't provide a way to store data in a long-term database either. Nor it takes multiprocessing, multithreading and server synchronisation into account.

TL;DR: These aren't low hanging fruits and need proper documentation, discussion and testing.

Permanent data currently only includes the online_support_code->*capcom_id association; these associations will be stored in a proper database once one is created, and should as such be kept in the database.py module.

Keep in mind that this module is meant to be a generic interface for any/future database engine. It could be a python dict, a local database or a distant one. Only storing, the support code and capcom_id isn't (shouldn't be) enough to authenticate the player across several servers. The support code identifies the console, the Capcom ID the player identity but they don't identify the current session (which is done by the PAT ticket, IIRC).

However, every other currently implemented storage mechanism (the server list, the gates list, the players lists, etc) are not going to be stored in the long-term database

Moreover, the database need to store, at the very least, the servers list in order, especially not to query each one of them when a player want to select/join them. Sure, it will need to be updated from time to time, it could be a local database or a structure in memory but a single FMP server can't know on its own how many servers are available from distinct local/distant FMP server instances.

Furthermore, once each server process is responsible for a single Server instance, the distinction between state and database will be much more important. Each Server will then be responsible for its own list of Players, Gates, Citys, etc.

Unless we know for sure that's going to be like that, let's not restrict ourselves like this. Scalability is key, If one FMP instance can handle one or more in-game servers, let's write clean code so it can just do that and fit the needs. Even if a server is responsible for its players, these players need to be found by other instances too, so their state need to be known globally (either by caching it in a database or requesting its state from the server the player is connected to) .