preDexing helps repeat builds run faster, but slows down builds that do
not have any caching.  CI builds start from scratch each time.  Turns
out that GitLab CI, Travis CI, Circle CI, and probably many others all
define the "CI" environment variable, so its easy to detect when running
in a CI environment.  This makes things a lot cleaner.

* https://docs.gitlab.com/ce/ci/variables/README.html
* https://docs.travis-ci.com/user/environment-variables/
* https://circleci.com/docs/2.0/env-vars/
* https://github.com/codepath/android_guides/wiki/Setting-up-Travis-CI
* https://stackoverflow.com/questions/23137764/building-a-debug-apk

If a repo is set with the gitlab-ci Secret Variable DEBUG_KEYSTORE and
there is a repo named the same as this repo with -nightly appended,
then this will automatically generate an fdroid repo of each build
produced by gitlab-ci runs on the master branch.

closes fdroidserver#256

The connected10 test runner has been at least as reliable as connected24,
and provides valuable coverage, especially for localization related
crashers.

clbin is just for making the logs easy to read, if it fails, the build
should not be marked as failed, especially since the logs are probably
not needed if the rest of the job succeeded.

This test now shows the actual blank/unused translations, so it should
be a lot clearer why this test is failing.

!519

Since we have all these lovely scripts for cleaning up the
translations, gitlab-ci is a handy way to enforce that they get used.
Since weblate merges happen via merge requests, this will work nicely
now.  I can't think of any false positives that will arise, but we
shall find out!

I think we should just move all the scripts to tools/, app/tools is
confusing, not very visible, and non-standard.

connected24 tests are frequently failing saying that while an emulator
is running, its not compatible.  This is bizarre. This just adds debug
output to help troubleshoot that.

'client' is no longer generated.

closes #858

* new docker image: ci-images/client
* switched back to ARM emulator, now that gitlab doesn't allow KVM

The emulator will grab a bunch of RAM, so run assemble before
connectedCheck so that the app is mostly built before starting the
emulator.

Avoid broken builds when fdroidclient gets out of sync with
ci-images/client.

`emulator -no-skin` no longer does anything, but give a warning.

* x86 emulator requires kvm which isn't always available on the
  GitLab CI runners.

Although these didn't used to fail at all, they now _always_ fail due to
the Docker setup we run on GitLab. Until we get that fixed, the CI is
not very helpful if it fails every time, and we merge anyway. This
allows us to at least correctly use the "Merge when succeeds" behaviour.

gitlab-ci used to run all of our jobs in parallel, now it mostly seems
to run them sequentially.  So splitting up the various parts of the CI
suite into separate jobs mostly slows things down.  This combines the
static tests into one job (lint, pmd, checkstyle, tools) with the JVM
tests aka Robolectric.  That makes three jobs from the previous six.

The new CI image also contains the support repo r41, with the support
libs version 25.1.0.

Unfortunately, something in the way that the docker image is created is
making it impossible to run `android update sdk`. Even though it runs as
root, it cannot upgrade things, and in the process, it seems to break the
Android SDK bits that are there.

  Installing Android Support Repository, revision 40
  Failed to rename directory /android-sdk/extras/android/m2repository to /android-sdk/temp/ExtraPackage.old01.
  Failed to create directory /android-sdk/extras/android/m2repository
  Done. Nothing was installed.

A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
   > You have not accepted the license agreements of the following SDK components:
     [Android Support Repository].
     Before building your project, you need to accept the license agreements and complete the installation of the missing components using the Android Studio SDK Manager.
     Alternatively, to learn how to transfer the license agreements from one workstation to another, go to http://d.android.com/r/studio-ui/export-licenses.html
   > Could not resolve all dependencies for configuration ':app:compile'.
      > Could not find com.android.support:support-v4:24.2.1.
        Required by:
            project :app
      > Could not find com.android.support:appcompat-v7:24.2.1.
        Required by:
            project :app
      > Could not find com.android.support:support-annotations:24.2.1.
        Required by:
            project :app

This makes sure that the latest version of the core SDK components are
all current before running, which means that the builds will keep
working even when the docker image gets out of date. Then we can
finish the task we are working on before having to deal with updating
the docker image. Without that update line, we have to drop everything
and update the docker image when things are out of date.

Disk space and bandwidth is cheap, developer time is very scarce. We
should aim to keep the tests working as much as possible so that we
waste less developer time. Updating everytime only means it downloads
a little bit of XML each time, that's nothing compared to what gradle
downloads on every build.

It also reduces redundancy by using before_script and after_script blocks.

connected10 is still flaky since the emulator crashes a lot.  Marking it
for "allow_failure" will still show a warning, but it won't fail the build.

We have to work harder to get writeable dirs in the android-10 emulator.

The latter is simply to include the newer version.

recommended here, seems like it can't hurt:
https://docs.travis-ci.com/user/languages/java/#Caching

Minor bugfix release.

Also bump the CI image with the new stuff.

Right now there is only one test in there anyway, so hopefully this is
a good tradeoff in terms of our time wasted vs not being able to run
those tests.

As long as we're stuck with 32-bit on the buildserver, avoid both target
and build-tools 24. Necessary to do an alpha.

Also bump the docker image since it contains the newer support m2 repo.

The connected checks on both emulators ran fine more than 30 times
without these. No noticeable slowdown either.

The connected10 build is not yet stable, and it has odd crashes.  So it
should not affect the overall success/fail marking. For example:

https://gitlab.com/eighthave/fdroidclient/builds/1430790