Try different jdk versions in sequence

[keynmol]

• Preload JDK 17, 11, 8 into the container
• Try each one until the indexing succeeds

The order might be wrong, may be should swing wildly - 17, then 8, then 11.

This change allows indexing https://github.com/indeedeng/proctor - first it tries 17 and 11, fails on both, then 8, produces a valid SCIP index.

Additionally:

• Switch to a base JDK 17 image

• Install Gradle the same way we install Maven, for consistency

  This also removes gradle from being the entrypoint of the docker image, which was confusing
  Good time to make scip-java itself the entry point

Test plan

• Add problematic repo to docker CLI test list

[olafurpg]

This makes sense. I've been wondering for a while if this is the way to go but didn't like the idea of running scip-java index in a for loop, and I can imagine some pathological case where the indexing step fails very late causing the indexing job to become 3x slower (and eventually Nx slower when we have N JVM versions)

[olafurpg]

Is it worth making this a matrix build so these can fail independently? Also in parallel

[keynmol]

I can make this parallel within the job itself, but given that I hope to have 5-10 repos in here, I think this will make matrix build too big - and each job will have to suffer the penalty of publishing docker CLI.

In a next PR I will make this faster by using GNU parallel and mounting cache folders into the containers.

[olafurpg]

Sounds good. It's very valuable to have a complete e2e testing pipeline but if the job becomes too slow then we can consider making it optional in PRs behind some GH label. Many PRs don't influence auto-indexing stuff and it sucks when the CI takes +30 minutes