[Server support] - Adds server support to `memo`

Central issue to track the Server support for memo.

Why

Adding a server will allow memo to:

Cross-device support.
Store user's "progress" in the cloud, drastically improving the experience.
Pushing collections updates without needing to deploy new client version to their respective stores.
... and many more features that are usually hard implement while using only a local database.

This will inevitably make this project structure way more complex, but it's almost inevitable given the use-case of this application.

Constraints to these changes:

The application's (client) offline usage should still be supported after these server changes.
The server should be - ideally - fully structured applying the infrastructure as a code (IaC) "strategy".
Last but not least, it should be 100% OS - very likely using this same repository as a monorepo.

How

At the time of writing, we already tackled both core starting point decisions to this:

[x] Decide which infrastructure and cloud vendor to use.
[x] Plan database structure, taking into consideration current and planned features.

Decide which infrastructure and cloud vendor to use

To summarize the first, the decision was to use Firebase because:

All of the requirements (and the ones that may come up ahead) match really well with the client-oriented solutions they provide - meaning less work for us at the expense of some caveats described below.
Will arguably make the 100% IaC strategy easier.
Flutter + Firebase community and supporting packages are 10/10 - and by obvious reasons.
Extra: team is more experienced with Firebase products, if comparing to AWS and GCP.

There are caveats when making this decision, like having a less flexible (and arguably a less robust) server solution, "severe" vendor-locking, etcetera. We are fine with this, as it seems that the pros outweighs the cons, when comparing the same in AWS or GCP.

Plan database structure, taking into consideration current and planned features

We opted to restructure the current (local) NoSQL database to a more "intelligent" model, solving limitations that we had previously, allowing easy scaling for future modifications and also being more cost-efficient while making read/writes. This rewrite can be seen in this image, summarizing the first version of this remodeling, although subject to change until the final release.

Side-note: This could look kind of confusing, but the problem is that we have to deal with a bunch of aggregator fields, or even properties that must be calculated using the dates - like all memo's average memory recall for a single collection.

Pending discussions to be resolved

[ ] Will we migrate the local stored data to the cloud?

Issues

The server should be considered completed after all issues below are closed.

Firebase

Flutter

[NEW] Because https://github.com/olmps/memo/issues/214 feature will also need to be connected to the server, we must also attach all required domain/data logic to make the functionality to work properly:

[ ] TODO(matuella): Create a proper issue with all business requirements when https://github.com/olmps/memo/issues/214 is merged.

This will be worked on server branch, which will be eventually be merged to main when we consider it stable.

olmps / memo