feat: add DB initialization module

[7flying]

This provides an interface defining the methods that we expect to be used for OV handling operations.

Added an implementation for sqlite and postgress. I have been unable to make the implementation more generic (aka just one definition of each of the functions of the lib) with a trait with two generic types instead of one, because the Connection trait (which holds SqliteConnection and PgConnection) cannot be made into an object. But I'm happy to learn how to refactor it if someone has ideas.

Added db creation files and tests, the PR is marked as draft since I still need to wire the tests to our upstream CI, making just the sqlite dependencies required, we don't want to install a postgresql server.

Update: This also adds the capability to select the DB storage method in the relevant server configuration files, the store interface implementation, and two new functions in the fdo-owner-cli in order to export OVs from the manufacturing server and import OVs into the owner-onboarding server.

[7flying]

Moving this PR back to draft since we need separate sql initialization files.

[7flying]

Updated, there are now three different databases.

Build/tests blocked until https://github.com/puiterwijk/rust-openssl-kdf/pull/16 goes in and a new release is made.

[7flying]

Force pushed to get the openssl-kdf update in.

[7flying]

Onboarding with DB sqlite implementation done, I need to take care of a couple of things: warnings on CI, add more tests, rewrite some commit messages (maybe merge some of the last commits). Then add the postgreslq part.

[7flying]

I'm moving some commits around and merging some others to make the PR more readable.

[7flying]

Added fix(data-formats): error when trying to parse an empty slice and moved it up before the fdo-owner-tool additions since the empty slice check is related to the new OV import cli method.

[7flying]

@nullr0ute I have a packaging question: we will need to add all the new migrations_* folders to the different RPMs (those folders hold, for each database and server type, the sql files that initialize/tear down the database), where would we place those folders?

[7flying]

Rebased on main, added docs.

[7flying]

Fixed some typos

[henrywang]

@7flying Test for postgres added and passed. Could you please give it a review? Thanks.

[7flying]

@7flying Test for postgres added and passed. Could you please give it a review? Thanks.

LGTM, we are testing what we need, thanks :+1:

[7flying]

Rebased on main, changed .sql files' install dir to %{_localstatedir}/lib/fdo/migrations

[7flying]

Rebased on main, changed .sql files' install dir to %{_localstatedir}/lib/fdo/migrations

reverted that to %{_docdir}/fdo

[7flying]

this force-push reverts some of David's changes since he unknowingly deleted my new commit with his force-push, he will add his new changes later

[7flying]

Force pushed to update the docs commit, all ready.

[7flying]

The force-push addresses @djach7 comments

[7flying]

There are some things that look a bit strange to me like putting Manufacturer, Owner and Rendevouz traits and implementations in what should be a place for common things only. I would move all that code to the corresponding server dirs and leave the common code, if any, in the db directory.

Due to the way in which we control how the storage methods are selected in the configuration files, the common code needs to be placed in the store module, not in the db module, so that's why the common code is already there. The rest of the code, which are the sqlite and postgres implementations, is in a different module so that we can control via the module features which things we can turn on or off.