Implement data store service to fetch entity data from HTTP or file system

[wcalderipe]

This PR introduces the data store service responsible for fetching data from various stores based on the tenant's configuration.

Image 1: part of the diagram done in this PR.

The goals were to allow data to be stored in any store you'd like, plus simple extensibility for new protocols.

Image 2: data store design.

This PR doesn't solve any specific configuration per data store. For example, authentication will be likely different from repository to repository (e.g. basic auth for HTTP).

Note on key-value storage model

The simplicity of key-value storage comes with a few trade-offs:

• Schema validation is handled at the application layer. These need to be manually checked before writing and after reading.
• Schemas don't support versioning. Changing a schema will introduce a breaking change to any engine with historical data using the old schema.
• The key-value model is not designed for use cases that require listing data (e.g., finding all the tenants). To address this, we need to maintain an index of tenants in a separate key managed by the application. This approach is error-prone and won't scale (though scalability isn't an issue right now).

Note on Dependency Inversion Principle (DIP)

The design of the data store service follows the DIP, making it the most hexagonal/clean architecture implementation in our codebase today.

A quick refresher on DIP: high-level modules should not depend on low-level modules. Both should depend on abstractions.

Applied to our structure, this means the core should not depend on anything outside the core. You can see an example of this in core/repository/data-store.repository.ts, which is just an interface, but in other places where we just need one repository the interface step is ditched.

By now, you might be wondering why we don't apply this approach everywhere. The reason is simplicity. It's tedious and difficult to abstract something when you have only a single sample. More importantly, code navigation becomes challenging.

Regarding code navigation, if your services only depend on interfaces, attempting to navigate to the implementation of an interface will lead you to the interface itself—which is correct but probably not what you want. You're likely interested in the actual implementation at runtime. However, to find the actual implementation, you'll have to figure out how the runtime injects the right implementation in the abstraction.