Bootstrap RESTful API and CLI

[ppanopticon]

Task Description

The use of RESTful API and CLI should be bootstrapped:

• [x] The RESTful API should be structured around schemas (i.e., a call could look like this <schema> <command>
• [x] The CLI API should be structured around schemas (i.e., a call could look like this <schema> <command>
• [x] Obviously, there are also global (i.e., schema independent commands).

Dependencies

None

Boundary Conditions

RESTful API should use Open API if possible.

[ppanopticon]

I have now (re-)structured the project (yet again) as follows:

• vitrivr-engine-core provides necessary base classes and specifications for the entire stack. It's a common dependency for all other projects.
• vitrivr-engine-base provides the default vitrivr functionality (e.g., default features, Cottontail DB database connectivity). In principle, it's an optional dependency.
• vitrivr-engine-index and vitrivr-engine-query are mere libraries, that provide functionality and logic for retrieval and indexing (independently of any API or plugin)
• vitrivr-engine-server is the new, default server that provides RESTful API and CLI functionality.

The argument for splitting this is as follows:

• vitrivr-engine-server provides an out-of-the-box infrastructure that can do retrieval and index via CLI and REST
• vitrivr-engine-base provides us with the default feature set offered by vitrivr (features etc.)
• vitrivr-engine-index and vitrivr-engine-query are libraries that can be used, if one wants to leverage vitrivr-engine but needs to provide access via a different type of API, e.g., a gRPC API or a API for a custom use-cases (e.g., we could use this to create the legacy API)

The API offered by the vitrivr-engine-server is now structured as follows:

• CLI and RESTful API offer certain global commands (e.g., to list available schemas)
• All query and indexing related commands are grouped per schema (e.g., about to get information about a schema via API).

@lucaro Any thoughts if this makes sense?

[lucaro]

Sounds reasonable to me. I guess this is largely in line with previous discussions. From a build-pipeline point of view, this would mean that we would build vitrivr-engine-index and vitrivr-engine-query as libraries and push them to a maven repository, build vitrivr-engine-base as a library and release it on github and build vitrivr-engine-server as an application and release it on github. For the application, I guess there would be two flavors, one that includes the vitrivr-engine-base and hence comes with 'batteries included' and one that does not, in case people just want to load their own libraries. Thoughts?