Applications API v2

[romanwozniak]

Context:

Until now, the information about enabled CaraML applications in the MLP deployment was persisted in the DB and retrieved from there via an API call. In the hindsight, that wasn't the best design decision, because it was required to add DB migration script for adding/modifying the app configuration, which in turn required releasing the new version of the mlp app.

Also, the information about the available CaraML applications conceptually belongs to the deployment configuration, because the same version of CaraML can be deployed with a different subset of CaraML applications (e.g. it should be possible to deploy CaraML with Merlin, but without Turing etc.). It's harder to achieve this, because the DB migrations are strictly versioned.

This MR attempts to solve this issue by introducing Applications API v2, which retrieves the information about CaraML applications from the runtime configuration and doesn't persist this data in the database. This refactoring is also done in preparation to embed CaraML microfrontends into the mlp host UI.

Changes:

• Refactored CaraML API layer to support both v1 and v2 endpoints simultaneously
• Refactored MLP UI and @gojek/mlp-ui components library to use /v2/applications instead of /v1/applications
• Refactored MLP landing page to only show information about the resources if the application that owns such resources (i.e. models -> Merlin, routers -> Turing etc) is enabled

Next Steps:

Since the frontends of CaraML apps are still using /v1/applications, it's required to keep this API endpoint until these apps are updated to use the new version of @gojek/mlp-ui. After it's done, Applications API v1 can be completely removed from the codebase.

[deadlycoconuts]

LGTM! 🚀 Thanks for the extensive refactoring; just had a couple of minor questions but no comments besides that!

[romanwozniak]

@deadlycoconuts thank you for the review 🙌