Integrate Equinox launcher and executable natives build into the Equinox Jenkins pipeline

[HannesWell]

At the moment the Equinox launcher and executable natives are build in a set of separate Jenkins Freestyle-job which are only triggered manually and push the built native binaries to https://github.com/eclipse-equinox/equinox.binaries:

• https://ci.eclipse.org/releng/view/Launcher/

This setup has the potential to forget to trigger the natives rebuild once a change was merged and makes it harder to understand and maintain the build-pipeline.
Therefore, even tough the Equinox natives are not built that often, I propose to migrate the mentioned set of Jenkins freestyle jobs into the Equinox Jenkins Pipeline and let that pipeline trigger the native builds on demand (i.e. if there have been changes), similar to how it is done for SWT.
This has the advantage that the exact build procedure is defined as code in this repository (always up-to-date), the natives can be build during PR validation, it reduces the number of Jobs in the RelEng JIPP and will also help for #559.

The launcher/executable build is currently performed in the RelEng JIPP, which has specially prepared platform specific build machines available as Jenkins agents that are capable to perform these builds.

The main question to answer is how we make these required special Jenkins agents available for the Equinox build pipeline?
When doing the same for SWT (in eclipse-platform/eclipse.platform.swt#514) there where basically two options:

1. Move the equinox Jenkins Job from the Equinox JIPP to the RelEng JIPP
2. Add the special build machines as extra agents to the Equinox JIPP.

For SWT option 1 was chosen since it was easier for @fredg02 to just move the eclipse.platform.swt job from the platform to the releng JIPP. I assume it's the same in this case.
Option 2 would be the cleaner solution from a build separation point of view, further more the RelEng JIPP is quite busy and contains the long running I- and Y-builds that regularly occupy a lot of resources, especially the special platform specific build machines, but sometimes even the basic ones.
This is already an inconvenience sometimes with the SWT build and mitigations are discussed in https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4231#note_1749789

A third option could be to move the sources of the launcher+executable (i.e. the org.eclipse.equinox.executable.feature project) and the launcher projects into a separate repository (for example equinox.natives or equinox.launchers or equinox.executables) together with the launcher+executable binaries using Git-LFS (Moving the launcher+executable binaries into this repository was already discussed in eclipse-equinox/equinox.binaries#1, but wasn't appreciated).
The Jenkins pipeline for that repository could then be moved to the releng JIPP and would only run on changes in the native launcher/executable sources. Since this happens less often, sometimes waiting longer for builds to complete wouldn't be such of an issue.
Using Git-LFS would also simplify to synchronize the native sources and binaries. The downside would be, that depending on where exactly would do the cut (e.g. would org.eclipse.equinox.launcher also be moved or only its fragments) some synchronization should also happen. Furthermore it would be difficult to test changes that requires adjustments in native and java code together in one verification job.

@tjwatson do you have any preference or would you be fine with any solution?

[tjwatson]

@tjwatson do you have any preference or would you be fine with any solution?

For option 1 or 2 does that imply the binaries for every supported platform would be built with each PR to the equinox repository, regardless of if the PR touched native code or not? If so then I would prefer to separate out the native code to another repository somehow, or figure out how to only trigger native builds if native code changed.

[HannesWell]

@tjwatson do you have any preference or would you be fine with any solution?

For option 1 or 2 does that imply the binaries for every supported platform would be built with each PR to the equinox repository, regardless of if the PR touched native code or not?

No, it wouldn't. Similar to SWT I it would only run if there have been changes in native sources, which is implemented in SWT at:
https://github.com/eclipse-platform/eclipse.platform.swt/blob/182518f95f4179b0e0d3205167a5d5eef8e61bb2/Jenkinsfile#L154

Just, like for SWT we only would need to tag each commit on the master for which binaries have been build, but that can be done automatically when pushing the just build binaries to the equinox.binaries repo as part of the master build (like done in SWT).

[tjwatson]

No, it wouldn't.

Then I don't have a strong preference.