Add maven-java11-nuxeo pod template and import needed repositories in the Jenkins X platform team

To run the platform unit tests, see NXP-27504, we need a pod template to:

• Customize the _JAVA_OPTIONS
• Define a Maven container:
  • Based on a custom image extending the builder-maven-java11 one provided by Jenkins X and including the required conversion tools.
  • With some custom CPU and memory requests and limits.

Then we need to import the following repositories:

• https://github.com/nuxeo/nuxeo-jenkins-x-builders
• https://github.com/nuxeo/nuxeo

------------------------------------------------------------------
Extract of myvalues.yaml:

PodTemplates:
  Maven-Java11-Nuxeo:
    Name: maven-java11-nuxeo
    Label: jenkins-maven-java11-nuxeo
    EnvVars:
      ...
      JAVA_TOOL_OPTIONS: "-Dsun.zip.disableMemoryMapping=true -XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90"
    Containers:
      ...
      Maven:
        Image: $DOCKER_REGISTRY/nuxeo/builder-maven-java11-nuxeo:0.0.1
        RequestCpu: "3"
        RequestMemory: "4Gi"
        LimitCpu: "4"
        LimitMemory: "8Gi"
        ...

Basically we've:

• Replaced _JAVA_OPTIONS by JAVA_TOOL_OPTIONS compared to the maven-java11 pod template provided by Jenkins X.
  According to https://circleci.com/blog/how-to-handle-java-oom-errors/

  It's a safe choice for setting Java memory limits. It’s read by all Java virtual machines and is easily overridden, either with command-line arguments or, depending on your build tool, more specific environment variables. It’s also better at handling quotes than _JAVA_OPTIONS.

  Whereas

  _JAVA_OPTIONS is the most powerful Java environment variable. It’s read directly by the JVM and overwrites any other Java environment variables, as well as any arguments you pass on the command-line (i.e., java -Xmx512m -Xms64m). For this reason, _JAVA_OPTIONS_ isn’t typically recommended — a more focused approach usually gets the job done just as well.

• Removed the "-XX:+UnlockExperimentalVMOptions" and "-Xms10m -Xmx192m" JVM options compared to the maven-java11 pod template.
  Indeed, this way any Java process will try to use the maximum memory available in the container (default behavior in Java 11), and each pipeline should set its own JVM options depending on the build requirements. Typically with MAVEN_OPTS, see https://github.com/nuxeo/nuxeo/pull/3150/files#diff-58231b16fdee45a03a4ee3cf94a9f2c3R54.
• Defined the "Maven" container image as the "nuxeo/builder-maven-java11-nuxeo:0.0.1" one built in the context NXBT-2902.
  See the 0.0.1 release, the Dockerfile and the Skaffold build directive.
• Increased "RequestCpu" and "LimitCpu" to allow parallel Maven compilation.
• Increased "RequestMemory" and "LimitMemory" to fit the Maven compilation and test needs. Indeed, with lower limits, the pod would get OOMKilled because it was exceeding the memory limits.
  Will have to investigate to better understand the behavior of the Kubernetes pods launched by Jenkins X and to find the right values.