Merge `mapping.example` and `network.settings` to one generalized settings file

[erichaagdev]

We should merge these two files to one common settings file (e.g. config.properties/settings.properties). This reduces the number of files and provides us with a file to add more generalized configuration options.

Required changes

• Replace network.settings and custom value mapping files with a default.config file
  • Update the fetch-build-scan-data-cmdline-tool to read both network settings and custom value mappings from default.config.
• Replace -m, --mapping-file with -z, --config-file
  • If the user provides a config file with --config-file, the settings override those in the default config.
    • If a setting is in --config-file, then use it over all other settings
    • If a setting does not exist in --config-file, but it does in /config and it is different from the universal default, then use the setting in /config.
    • If a setting does not exist in the --config-file and it also does not exist in /config, then use a hard-coded default value (same default as what is used today).
• Output the config file at the start of the script run
  • If a user provided a config file as an argument to the script, show the location of the user-provided config file.
  • If no config file is specified by the user, output the location of the default config file.
  • If the default config file has been deleted, show <none> to indicate that no config file was applied.
• Include the "effective config" (the configuration after all overrides are resolved) in the experiment run directory.
• Update interactive mode
  • For Gradle Exp 01, 02, 03, and Maven Exp 01, 02:
    • Add collection step to ask for a config file that overrides the default config.
      • Link to the section in the README that discusses configuration settings.
  • For Gradle Exp 04, 05, and Maven Exp 03, 04:
    • Replace the custom mapping file collection step with the collection step to ask for a config file that overrides the default config
      • Link to the section in the README that discusses configuration settings.
    • Remove the mapping file end-of-experiment explanation
  • Include -z in the command to repeat the experiment.
• Update the Build Validation Script README files
  • Group the mapping configuration and network settings under a Configuration section.
    • The existing mapping and network setting sections are already listed together, so grouping them under a common Configuration section header should be okay.

[etiennestuder]

Some thoughts:

• should we call the default file default.config? (one could then also have additional files like spring.config, etc.)
• I would use -z for the cmd line param
• we also need to update the --help output when we change from -m to -z
• we also need to update the cmd we print at the very end in interactive mode
• we should debate whether or not to include the config file path in the summary (the only thing not directly related to the build)

[jthurne]

👍 Description updated accordingly.

[erichaagdev]

The availability wait timeout for Develocity API calls would be a nice configuration option to have.

#791