feat: persistance layer

[oSumAtrIX]

About

The API has been designed to be entirely static, which is why an in-memory database is currently used. Because of upcoming features such as #42 this design may be problematic.

Solution

An interface must be introduced that allows swapping the persistence layer. Along the in-memory, an on-disk persistence layer implementation for the interface must be provided that can be chosen at build time or via a configuration file.

Additional context

The ability to migrate between the interfaces may exist.

[alexandreteles]

There is no persistence layer in the API itself now; the cache is handled at the proxy level. The persistence layer would be used by endpoints like /announcements and /changelogs I suppose? If so, I might need to take care of that issue before I delve into this one.

[oSumAtrIX]

The persistence layer should be introduced with an abstraction layer that allows switching out of the implementation as long as it follows the designed interface as specified in the issue description:

An interface must be introduced that allows swapping the persistence layer. Along the in-memory, an on-disk persistence layer implementation for the interface must be provided that can be chosen at build time or via a configuration file.

Use cases of this feature would allow introducing of other features as described:

Upcoming features such as #42

[alexandreteles]

Yeah, that's what I thought. This will be quite a significant feature, and I don't feel like writing and maintaining an ORM for ReVanced, so I might default to Alchemy and write the abstraction on top of it using a relational approach. I will need some time to consider this carefully.