Materialize Maven-based job dependencies before SNAPSHOT changes

Maven jobs relationship is automatically calculated based on the Maven dependencies after the first build.
When the version changes, those dependencies are recalculated during the POM analysis. If the new dependencies are not yet available, then it can lead to a wrong build order and a failing first build for those of the jobs which built before there expected upstream job.
This race condition happens after a release, when the whole platform is updated:

• a hundred of jobs are triggered for a build,
• while their POMs are analyzed, they are loosing their respective relationships based on the old SNAPSHOT version and are looking for a job producing the new version.

A solution is to hardcode the job relationships so that they are independent of the SNAPSHOT version.
Jobs relationships are not expected to evolve on maintenance branches: this solution can be used for HF releases.
However, that is not acceptable on master, where we need to keep the dynamic relationship behavior.

=> with a Groovy script (scriptlet or pipeline):

• programmatically walk through the automatic Maven-based job dependencies starting from a root job,
• output the list for human validation,
• materialize the dependencies as hardcoded upstream dependencies (the child subscribes to the parent).

=> and a second script:

• programmatically walk through the Maven job dependencies starting from a root job,
• if the jobs have Maven-based dependencies (and/or if the last build was successful), then display the diff versus hardcoded dependencies and ask for confirmation for removal