refactor(local deployment): parametrize partners

[tom-rm-meyer-ISST]

Description

Currently we got the bpn in the generate-keys.sh hardcoded. This pr puts them as changeable parameter into the beginnning. This allows us to easier create an INT environment.

Further:

• fixes wrong keycloak port so that the integration tests don't fail anymore (introduced accidentally in #1066)
• added missing version bump in openApi

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

• DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
• Copyright and license header are present on all affected files (TRG 7.02
• Documentation Notice are present on all affected files (TRG 7.07)
• If helm chart has been changed, the chart version has been bumped to either next major, minor or patch level (compared to released chart).
• Changelog updated (changelog.md) with PR reference and brief summary.
• Frontend version bumped, if needed (frontend/package.json, frontend/package-lock.json)
• Backend version bumped, if needed (backend/pom.xml)
• Open API specification updated, if controllers have been changed (use python script scripts/generate_openapi_yaml.py with running customer backend)

[ReneSchroederLJ]

Great work thank you for the contribution. Makes it much easier to change key parameters.

One thing I noticed is that while we use the environment in most instances there are some places where we still use hardcoded values. One example are the constants for the wallet mock.

Do you think we should address this to make sure that changing the BPNLs in the generate-keys script does not have unwanted side effects?

Since the mock is not the default anymore I would not see this as a reason to block the PR, but it's worth considering.

[tom-rm-meyer-ISST]

Great work thank you for the contribution. Makes it much easier to change key parameters.

One thing I noticed is that while we use the environment in most instances there are some places where we still use hardcoded values. One example are the constants for the wallet mock.

Do you think we should address this to make sure that changing the BPNLs in the generate-keys script does not have unwanted side effects?

Since the mock is not the default anymore I would not see this as a reason to block the PR, but it's worth considering.

I incorporated the change for the ssi-dim-walllet-stub and would not do it for the mock as this is quite hard. I checked whether it's working by changing customer and supplier bpnl (not part of the commit)

[ReneSchroederLJ]

I incorporated the change for the ssi-dim-walllet-stub and would not do it for the mock as this is quite hard. I checked whether it's working by changing customer and supplier bpnl (not part of the commit)

Makes sense to me. Thank you for checking.

[ReneSchroederLJ]

LGTM thank you for the effort.