EIM decomposition - provide scenario specific API

[jkossak]

Description

This PR adds ability to expose api endpoint per scenario requirement by enabling/disabling related grpc clients/services inside apiv2 - based on scenario manifests included in the repo.

Related PRs:

• Add 'eimScenario' flag to apiv2 chart infra-charts#277
• Enable EIM scenario setup edge-manageability-framework#1349

Fixes # (issue)

Any Newly Introduced Dependencies

Please describe any newly introduced 3rd party dependencies in this change. List their name, license information and how they are used in the project.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist:

• I agree to use the APACHE-2.0 license for my code changes
• I have not introduced any 3rd party dependency changes
• I have performed a self-review of my code

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[niket-intc]

Why do we need a separate code to generate a go file (allowedlist_gen.go) file.
Why cant we manually create the file and keep it. And Edit it with more scenarios when needed.

Or directly take the services name from the Helm chart values files from user. This way its more maintainable.

[jkossak]

Why do we need a separate code to generate a go file (allowedlist_gen.go) file. Why cant we manually create the file and keep it. And Edit it with more scenarios when needed.

Or directly take the services name from the Helm chart values files from user. This way its more maintainable.

We don't strictly need it. We could manually create the go file. However, having the list of services per scenario in the yaml file makes it easier to locate and modify by someone not familiar with the code. Scenario definitions are closer to configuration rather than the application logic. Plus, now the tool validates the names of the services in the manifests against the implemented gRPC services names (just added). If the manifest contains not implemented services - the code generation fails early rather than at runtime.