fix: values in user's profile_default are ignored

[jhaeu]

Pull Request Checklist

• 1. I have rebased the latest version of the main branch into my feature branch and all conflicts
  have been resolved.
• 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
  [Unreleased] heading.
• 3. I have documented my code using JDocs tags.
• 4. I have removed unnecessary commented out code, imports and System.out.println statements.
• 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
• 6. I have created API configuration tests for any new functionality exposed to the API.
• 7. If changes/additions are made to the ors-config.json file, I have added these to the ors config documentation
  along with a short description of what it is for, and documented this in the Pull Request (below).
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
• 10. For new features or changes involving building of graphs, I have tested on a larger dataset
  (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
• 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
  importer etc.), I have generated longer distance routes for the affected profiles with different options
  (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
  points generated from the current live ORS.
  If there are differences then the reasoning for these MUST be documented in the pull request.
• 12. I have written in the Pull Request information about the changes made including their intended usage
  and why the change was needed.
• 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes #1762 .

Information about the changes

• Reason for change: See issue ors.engine.profile_default in ors-config.yml is ignored #1762 . The reason for the bug was, that properties that are set in application.yml ors.engine.profiles.* cannot be "overridden" by defaults defined in a user's ors-config.yml ors.engine.profile_default: The method merging profile properties and profile default properties does not know, if a profile property was defined in application.yml or in ors-config.yml, these files are already merged by spring. So properties from profiles.* always win.

• Key functionality added: Profile properties were moved from application.yml to application-profiles.yml. The latter is only loaded when the application is started with spring profile "profiles", which is not the default, but can be used for local runs. Started with the default spring profile, the profiles have no default values. Only exception is "ors.engine.profiles.*.profile" (bad property name BTW), which is fix for our basic profiles and should not be overridden by the user. The workflow to generate ors-config.yml and ors-config.env was adapted to generate configs composed of both merged internal yaml files, where all properties are active and not commented out. Only car is enabled.

Examples and reasons for differences between live ORS routes, and those generated from this pull request

Required changes to ors config (if applicable)

• Users that have already a ors-config.yml in use (e.g. generated from their json by using our transformation tool) have to un-comment all commented properties in their (enabled) profiles!
• Users still using a json config have to add missing properties in their (entabled) profiles. They should transform their json to yml with the help of our tool and then compare their existing ors-config.yml with our default ors-config.yml.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
71.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[sfendrich]

Overall it makes sense to me. Maybe we could go over it in a group with @jhaeu explaining.

[MichaelsJP]

Closing as not relevant any more. Has been solved in a better way by using externalized configuration from spring-boot.