feat(swagger-editor): customizable codegen URLs

[antoineauger]

Description

This PR aims at allowing users to customize the URLs used by the Swagger Editor codegen features (e.g., Generate Server and Generate Client).

The URLs that can now be customized are:

• swagger2GeneratorUrl: (https://generator.swagger.io/api/swagger.json by default)
• oas3GeneratorUrl: (https://generator3.swagger.io/openapi.json by default)
• swagger2ConverterUrl: (https://converter.swagger.io/api/convert by default)

For Docker users, this is made possible by the introduction of 3 new environment variables: URL_SWAGGER2_GENERATOR URL_OAS3_GENERATOR and URL_SWAGGER2_CONVERTER, respectively.

Motivation and Context

This PR can be interesting for:

• users who already have their own local Swagger generator server (https://github.com/swagger-api/swagger-codegen#public-pre-built-docker-images);
• users who don't want to enable the codegen features (for instance for security reasons).

Fixes #1488
Fixes #2688
Fixes #2127

/cc @fgreinacher @dlouzan

How Has This Been Tested?

For Docker env variables, created several docker containers with various values for env variables URL_SWAGGER2_GENERATOR, URL_OAS3_GENERATOR and URL_SWAGGER2_CONVERTER. Then logging on startup:

console.log(mergedOptions)

Also tested that setting these variables to null was disabling the Swagger Editor codegen features:

docker run -e URL_SWAGGER2_GENERATOR="null" -e URL_OAS3_GENERATOR="null" -e URL_SWAGGER2_CONVERTER="null" -d -p 9999:8080 swagger-editor

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

🛠️ with ❤️ by Siemens

[char0n]

@antoineauger thanks a lot for contributing. We'll look into the PR ASAP.

[char0n]

Thanks for contributing! Please have a look at my code review comments.

[antoineauger]

Thanks for contributing! Please have a look at my code review comments.

Thanks for the review @char0n, this PR is way much simpler now.

I think I addressed all your comments, could you have another look at it? 🙏🏻

[char0n]

Nice work! Changes look good! I'll have to some local testing with changes from this PR before the merge.

[char0n]

Testing went fine. All works as expected. THanks again!