[INFRA-2562] Add 'Artifactory API' mode (plus considerable overhaul to get there)

[daniel-beck]

Deferred:

• Detect weird misbehaviors (same plugin version in different groupIds; both versions "X" and "X.0" exist; plugins with both "hpi" and "jpi" file) and automatically exclude them and log a warning. For now, affected releases are just suspended.
• Investigate why the new implementation finds additional releases of plugins compared to the previous one. My current guess is we're picking up incomplete/broken releases due to not relying on the Maven index. For now, affected releases are just suspended.

---

This rips out most of the "Maven" integration code that's been a mess for a long time.

While use of the Artifactory/Nexus Maven index remains the default, if ARTIFACTORY_USERNAME and ARTIFACTORY_PASSWORD are set, we instead use the Artifactory API to list and download artifacts.

Some details on the implementation:

• Pull up generic behavior from MavenRepositoryImpl into supertypes
• Add a parallel implementation ArtifactoryRepositoryImpl and choose the appropriate one in DefaultMavenRepositoryBuilder.
• Move ArtifactSource implementations into their respective MavenRepository implementations due to overlap. Was silly to keep them separate.
• Allow getting artifact files from local Maven repository/cache if they already exist there. Should make the migration easier.

This removes the dependency that the update center generation had on up to date Nexus Maven indexes. While the additional delay has been annoying for a long time, INFRA-2562 is a recent problem that made it quite a bit worse when trying to quickly push out security fixes.

Behavior changes

As this completely changes how plugin data is obtained, there are changes in behavior. In my testing, I've found the following differences in update-center.actual.json:

• All the dates are different, usually fairly small differences.
• sshd 1.2 (a module) was released as an HPI, so I need to blacklist this, as now it would show up in the list of plugins.
• Plugins that got released both with version "X" (e.g. 1.0) and "X.0" (e.g. 1.0.0) and/or the same release with different groupIds may show a different version than before. Blacklist them.
  • selfie-trigger-plugin-1.0 is in different groupIds
  • build-pipeline-plugin-1.0 and 1.0.0, also in differen groupIds
  • ibm-security-appscanstandard-scanner-1.0 and 1.0.0
  • text-file-operations-1.2 and 1.2.0
• templating-engine 1.0 has both HPI and JPI. Blacklist it.
• Additional releases of some plugins are detected, but it's unclear why. Perhaps incomplete uploads?

[oleg-nenashev]

I reviewed the new Artifactory code, and it looks legit. I also run the code locally, and it looks to be working much faster than the original version. Still much slower than 50s reported in another PR, but I have no mirror nearby :)

Approved assuming that: the new mode is documented, especially "How to enable it?"

I would also suggest to firstly deploy it on the experimental update center so that we can do some testing. Or maybe we could have a temporary update center like we previously did for Java 11

[oleg-nenashev]

Might be converted to an interface with default methods. It might be more convenient for future extensibility.
Will need getter/setter for pluginFilters, so might be YAGNI

[oleg-nenashev]

Move definition up in the class?

[oleg-nenashev]

Switch all messaging to java.util.logging?

[daniel-beck]

I will merge this tomorrow.

The only notable change appears to be the removal of selfie-trigger-plugin as its only release 1.0 has been released twice, and this change would pick up the other one (the blacklist doesn't support specifying groupIds).