Limit the backports to avoid breaking future LTS release after changes on the weekly tooling

This repository follows the branching model of the Jenkins core with:

It creates a risk (a real one as we regularly break LTS/security releases) that we do not reuse the technical changes by forgetting to backports.

It also creates complexity because of the need of this backports (1 backport PR for each "stable/security" branch).

Multiple paths to improve this:

Automate backports: having a daily/weekly job or bot that would open a PR from master to an automated list of target branches. Still complex but at least we would not forget (I assume that the list of "living branches" such as the "current LTS" can be defined in a text file and kept up to date, OR extracted from the git history in an automated and reliable way).
Stop using branching model for this repository: we mostly use 3-4 pipelines, with a shell script release.bash, a README.me and pod agent definitions. With the actual "properties file" that are per branch, we could instead store them on a local directory.
- There is commodity to have "1 pipeline job per line" in release.ci.jenkins.io. But this commodity could be kept by defining the jobs with configuration as code for release.ci, which would holds the "list of lines". No problem to automate the "line shift" when we change LTS baseline (updatecli, shell script, GHA, whatever).
- This new mode would open more "testing packaging process on each PR" to improve our confidence in updating this without breaking releases

jenkins-infra / release