Replace the custom DBMS in Core.Data with EF Core and SQLite

[0xlsca]

Currently, the GameServer and WebHost lack data acquisition from a database.
Core.Data appears to contain a custom, unfinished implementation.

I propose that instead of going with a custom implementation, replacing it with EF Core and SQLite should be considered.
Not only does the implementation of a custom DBMS come with heavy initial effort, but it also requires the implementing people to stick around and document the implementation so it can be picked up by others in case changes need to be made.

As a replacement, EF and SQLite seem to be highly viable, primarily because EF is an easy to use and well documented ORM and SQLite being a relational DBMS, essentially keeping the knowledge required for working on the database to a minimum.

Another quality of EF is the creation of migrations and as far as I understood it, this essentially allows us to switch to a different DBMS should the need arise (e.g. MariaDB or MSSqlServer).
SQLite is a good choice for the time being since it doesn't require any installation on the developer's side.
The project setup would remain unchanged.

[eXpl0it3r]

I've once started an attempt, but didn't really get far, as I had trouble configuring EF to work with SQLite.

If you have some experience with that, I'm more than happy to merge such a change. 🙂

[eXpl0it3r]

An alternative approach for the initial development phase that would allow for an easier interoperability with PacketPeep and faster loop, is to use simple JSON files. That way we don't have to necessarily define a fixed schema and don't have to deal with schema evolution etc.

It might be a bit more cumbersome when it comes to storing dynamic data, like player information, but I think that might not the primary focus. Switching from JSON loading to SQLite should then eventually also be a rather small step.