fix: evaluate profile_default

[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
• [ x 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 #1762 . The root cause for the bug is, 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.

This PR does not really fix the issue. Properties were moved from the application.yml's profiles section to profile_default. This was done for all properties where the same values were used for all profiles. The goal is, to not change behavior in existing ORS configurations if possible.

A real fix would be PR #1778 - but with the disadvantage, that users would have to change their enabled profiles in their ors-config.yml/env (see PR).

Or another real fix could later be implemented, e.g. defining defaults only in spring annotations in the code and generate ors-config.yml based on this.

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

Required changes to ors config (if applicable)

[takb]

lgtm

[jhaeu]

@takb Why did you re-introduce enabled properties in all profiles? This change was intended by me, and it was discussed with @MichaelsJP .

[takb]

@takb Why did you re-introduce enabled properties in all profiles? This change was intended by me, and it was discussed with @MichaelsJP .

just trying out things because the config conversion script is broken, no worries they're gone

[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