Support custom startup parameters for extensions

[tomakehurst]

Proposal

Allow extensions to register and consume their own startup configuration options so that e.g. WireMock standalone can be started with extra parameters like --my-extension-parameter=123

e.g. we could add an extra method to the Extension interface like:

List<OptionDefinition> getCustomStartupOptions();

And one to Options for retrieval:

Optional<OptionValue> getOptionValue(String key);

This should build on top of #2578.

References

No response

[tomakehurst]

@dirkbolte as we discussed last week

[dirkbolte]

Can/should we scope them to avoid conflicts between different extensions/wiremock core? Thinking about adapting something like spring's externalized configuration: --extensions.<extensionName>.<parameter>=<value> . Same scheme could also be stored in a properties/yaml/json file.

[tomakehurst]

I've wondered about that, then wondered if it's overkill. Not sure how likely it is that collisions will occur, but maybe I'm lacking imagination...

[dirkbolte]

My hope would be that this would not bloat the whole topic when it's added now - while it would be a breaking change when added later. If there would be at any time two extensions with conflicts, there's practically no way for a user to mitigate it and neither for the extension developers to adapt it with another breaking change.

I can imagine one use case where we might run into conflicts relatively fast: when having extensions for subsystems like Store. I can assume that the parameters for stores might be very similar (timings, URLs, credentials).

I would hope that users are very familiar with this notation, so this should hopefully not cause any usage issues.

[tomakehurst]

OK, agree playing it safe might be a good idea. How about just --ext.<extensionName>.<parameter>=<value> so it's not quite as many keystrokes?