Remove grisp_cryptoauth depency and introduce grisp_keychain

[ziopio]

This restructuring is needed to extend grisp_connect support to multiple platforms other then just GRiSP board variants.

Breaking changes

New required grisp_keychain settings in user configuration

Users of grisp_connect will have to add correct grisp_keychain enviroment values depending on the platform they are deployng to. This means that old projects will need to adapt.
For new projects we plan to extend rebar3 grisp configure command.

certifi

grisp_connect no longer injects the certifi:cacerts callback in grisp_cryptoauth nor in grisp_keychain.
Such option action needs to be added by the end user in the final configuration.
This PR reverts #41

Unifying the API to manage certificate

grisp_keychain is always used through its main module, not like grisp_cryptoauth.
Before this PR, grisp_cryptoauth_tls was used to fetch the options, now we simply call grisp_keychain.

New Options

board_certificate

Allows to customize the path where the board cert is stored for usage in a braid cluster, defaults to "/etc/board.pem"

allow_expired_certs

grisp_connect can insert a special verify_fun to ignore cert_expired errors during x509 path validation.
This is set to false a s default.

Simplifications

grisp, grisp_cryptoauth and grisp_updater_grisp2 dependecies have been removed. This simplifies profile builds and tests setups as no emulation or special flags need to be used to be abel to run the code.

Requirements to merge

• release grisp_keychain
• update lock file

[sylane]

IF this is only for development, does it make sense to be in the static configuration that will be used in production ?

[ziopio]

This path is actually used in grisp2 in prod. But on the kontron board we need to use /data
This path was hardcoded before, now is in default config and configurable.

[ziopio]

Or do you mean {allow_expired_certs, false}?
I like to have default values for any config in the app.src. It is a quick place to have them listed. This is cleaner then using get_env/3 which embeds the default value in the code.

[sylane]

I was talking about board_certificate, I didn't remember what it was. What about it needed to be writable ? This is an issue as etc will never be writable. The system would have to be setup to have /etc/board.pem be a link to either /tmp or /data, but where this certificate would come from and where will it be setup ? Sorry I just don't remember well what this certificate is about...

[ziopio]

This certificate is required by erlang distribution setup used in braid networks. It is referenced here: https://github.com/grisp/grisp_demo/blob/main/priv/ssl_dist_opts.rel

In grisp2 we need to read the certificate from the Secure element and place it on the filesystem to be available to Edistribution. This is why we were writing it in etc. In the case of the kontron, this is not needed (for now) as I have the certificate already on the filwesystem.

What happens is that the cluster module reads the cert from grisp_keychain and writes it in the board_certificate location.