Add a "build" phase to the GuestLanguage interface

Created by: muffato

Use case

The GuestLanguage interface requests a compilation of the wrapper every time a worker specializes into an analysis of that language. maven still taking ~10 seconds even if the wrapper is compiled and up-to-date means that the test-suite is considerably slowed down. This model also doesn't scale as potentially hundreds of workers would all be calling maven at the same time.

Description

In this PR I introduce a new phase of the GuestLanguage interface, "build", and a new script, {{refresh_guest_languages.pl}} to build all the wrappers. I also rename the "compile" phase to "check_exists". maven is not needed at runtime any more.

This allows some drastic changes to the Docker image. The Dockerfile is now a multi-stage build, maven being pulled in just 1 phase to build the wrapper. Then the final image only needs to include the JRE, not the JDK+maven. In fact there are now several more stages in the Dockerfile. This simplifies the handling of temporary tools that are only needed for one operation but not in the final image. I have also made the Dockerfile pull the whole checkout as "build context" rather than fetching it from Github (will have to reconfigure this on the Docker Hub). It greatly simplifies testing things locally and reduces the amount of data being transferred. That plus a few other changes, the eHive Docker image is now slightly more than 700MB (about a CD-ROM ^^). It was 1.12GB before

Possible Drawbacks

The pipeline won' be able to automatically pick up changes in the wrapper code. One would have to run {{refresh_guest_languages.pl}}. I think this is acceptable and quite typical (like having to rerun make in order to update the executable).

Testing

Have you added/modified unit tests to test the changes?

Already covered by tests.

Have you run the entire test suite and no regression was detected?

Yes