Integrate Mediterraneus protocol components for the participant onboarding

[xamcost]

Hi there! We got familiar with the mediterraneus protocol and its components through some testing and documentation provided by LINKS. The marketplace frontend currently features a wizard to onboard new participants, but it is not hooked to any of the components, since their scope are still being defined. The goal of this issue is to integrate the components to make this onboarding process fully functional.

So to consider this issue closed, we need to:

• have configurable docker images for each Mediterraneus components needed during the onboarding process.
• have a docker compose and/or some instructions to bring up the mediterraneus components for testing
• update the env variables of the frontend to point towards the mediterraneus components
• remove example resources in the onboarding wizard and make it work with the components
• update the README to indicate how to run the docker compose, and where to find the resources to perform the testing of functionalities like the onboarding (how to get dummy tokens from a given faucet, ...)

This issue should be address before the scopes of the Mediterraneus components are fully defined, i.e. until the following issue Sedimark/dlt-booth#6 is addressed.

NB: At the date of writing, the onboarding wizard (accessible upon clicking the register button) is the only functionality depending directly on the mediterraneus components. Other DLT interactions will be performed indirectly by other components (DS connector, and maybe also catalogue).

[psotres]

Several decisions were taken as a result of https://github.com/Sedimark/mvm-participant-onboarding/issues/4.

Marketplace frontend will interact with DLT Booth APIs. DLT Booth is part of the SEDIMARK Toolbox so we consider this interaction to happen within a single participant security domain (i.e. locally).

@mikeus9908 Could you please mention here the corresponding issues from DLT Booth project for reference? (e.g. Booth API definition, dockerization, ...)

[mikeus9908]

Since the booth is a fork of the mediterraneus connector, I do not expect to have major differences from the connector itself. Therefore the official mediterraneus documentation is still valid.
I planned to add a more summarized version into the README of the dlt-booth, including a docker-compose that can be used for testing/example.
For the API definition I may include the openapi spec in the repo.

I'm open to suggestions

[xamcost]

@mikeus9908 There are already a few things we can use, thanks for that. Something like the swagger-ui in the docs is actually good enough in my opinion. Indeed, we can just complement it with some example usage of the API in the README, explaining, for instance, how to create the payload to pass for the entities creation (the "ethAddress" generation for instance).

[xamcost]

@mikeus9908 And indeed, if there is any update needed to the Docker compose, or something missing in the docs about how to set up its env variables, we can review that together so we get integrate it in the frontend.

[mikeus9908]

@mikeus9908 There are already a few things we can use, thanks for that. Something like the swagger-ui in the docs is actually good enough in my opinion. Indeed, we can just complement it with some example usage of the API in the README, explaining, for instance, how to create the payload to pass for the entities creation (the "ethAddress" generation for instance).

Thank you for the suggestion, I'll try to be more descriptive on input parameters. Regarding the specific example you made, you should consider that the main difference is try to offload dlt interactions onto the dlt-booth (so this means that you won't need to pass signatures or ethAddresses anymore).

Moreover, if you need to test your frontend before the upgrades of the booth are ready, you might have a look at the mediterraneus demo to have a clear look on how the external wallet and the connector are working together.