Optionally abort startup when unknown configuration parameters were detected

[leonardehrenfried]

Summary

When managing a large number of deployments many configuration files need to be maintained and when upgrading to newer versions, it's easy to overlook that the configuration schema has changed.

There is already a validation system in place that prints warnings but it would be nice if you could make OTP fail loudly when the configuration is invalid. This way you'd notice straight away.

This PR adds this capability: you can pass the CLI param --configCheck and OTP fails to startup. This forces you to deal with the invalid configuration straight away.

Unit tests

✔️

Documentation

✔️

[leonardehrenfried]

cc @miles-grant-ibigroup @hbruch

[codecov]

Codecov Report

Attention: Patch coverage is 13.33333% with 13 lines in your changes are missing coverage. Please review.

Project coverage is 67.88%. Comparing base (0532203) to head (68f667e).
Report is 254 commits behind head on dev-2.x.

Files	Patch %	Lines
...opentripplanner/standalone/config/ConfigModel.java	0.00%	6 Missing ⚠️
...n/java/org/opentripplanner/standalone/OTPMain.java	0.00%	4 Missing ⚠️
...opentripplanner/standalone/config/BuildConfig.java	0.00%	1 Missing ⚠️
...g/opentripplanner/standalone/config/OtpConfig.java	0.00%	1 Missing ⚠️
...pentripplanner/standalone/config/RouterConfig.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5676      +/-   ##
=============================================
+ Coverage      67.77%   67.88%   +0.11%     
- Complexity     16474    16560      +86     
=============================================
  Files           1901     1908       +7     
  Lines          72121    72355     +234     
  Branches        7430     7443      +13     
=============================================
+ Hits           48881    49121     +240     
+ Misses         20727    20714      -13     
- Partials        2513     2520       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jtorin]

I can see the benefit of exposing the config validation logic outside of OTP. It would be possible to work-around it by analyzing the log for validation errors, but it's messy to do in an automated fashion, and to fully emulate the behavior the OTP process would have to be stopped. So this adds value.

However, I don't see that OTP sets an exit code, somewhat limiting the use in automated logic.

[t2gran]

My main consern with this PR is that the we opens up for an alternative way of setting up OTP. The design is well though through to support a wide range of deployments, while this PR is not. Supporting alternatives always require more maintenance. The code changes here are relative small, but we are likely to see other similar requests in the future. I have taken some time to think through this, and I do see it is useful for some deployments, so I will approve it (when my comments are fixed). I have also considered other strategies, but have not found one which would work in all cases with this strict validation applied.

This deviates from the main model/design. But, it supports simpler deployments. I have considered spliting environment specific config (including ways if filtering the config - supported today) and OTP tuning. But, it is not so simple. E.g. you may want to turn on a feature in the test environment, but not in the production environment.

[t2gran]

The doc is ok, just some minor stuff left.