GitLab

This fully replaces gradle-witness and goes far beyond what it offered. As
far as I can tell, this actually will verify every single artifact that
gradle downloads and uses.

This was generated in two passes to get both the PGP and the SHA256 info:

```
./gradlew --write-verification-metadata pgp,sha256 build connectedFullDebugAndroidTest --export-keys
./gradlew --write-verification-metadata sha256 build connectedFullDebugAndroidTest
```

Thanks to  @vlsi who made me aware of this, and helped make it possible.
closes !837

The emulators without KVM are just too slow to reliably run the Espresso
tests, at least with the timeouts that are set by default.

This reverts commit c5daf198.

Turns I was confused here.  Yes, the job has to be called "pages" if the
job is deploying to GitLab Pages.  But in the case of `fdroid nightly`, the
thing that is deploying to GitLab Pages is the .gitlab-ci.yml that is in
the *-nightly repo, which is auto-generated by `fdroid nightly`.

fdroidserver#649

There are soo many of these:

org.fdroid.fdroid.net.HttpDownloaderTest > downloadThenCancel[avd27(AVD) - 8.1.0] FAILED
Test failed to run to completion. Reason: 'Instrumentation run failed due to 'Process crashed.''. Check device logcat for details

based on https://aur.archlinux.org/android-emulator.git

gitlab.com says they always use 4GB instances now anyways.

https://docs.gitlab.com/ee/user/project/pages/getting_started_part_four.html#job

fdroidserver#649

The newest emulator releases always segfault when booting the trusty ARM
android-22 image.

The merge_requests feature is really confusing, and doesn't seem to do
anything useful for what we need it to.  Like it doesn't let new
contributors' merge requests run on the fdroid runners.

https://medium.com/zendesk-engineering/speeding-up-android-builds-on-travis-ci-1bb4cdbd9c62

It seems that ARM emulators timeout even when just trying to run the
assumeTrue() tests via Espresso.  There needs to be one test still enabled
in the file, otherwise, the run fails with:

org.fdroid.fdroid.MainActivityEspressoTest > initializationError[Nexus_One_API_19(AVD) - 4.4.2] FAILED
        java.lang.Exception: No runnable methods
        at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:191)

* seems that android-24-x86 emulator don't work without google_apis
* -wipe-data is required to use google_apis_playstore, otherwise adb fails:
  https://github.com/butomo1989/docker-android/issues/87

Caching proxies are a lot easier with plain HTTP.  HTTPS is not needed here
since these are only CI builds.  The worst an attacker could do it annoy us

Before, it was only including errors.

The emulator runs are super crashy on gitlab-ci, so just run the emulator
tests for the "full" build flavor.  Once these prove stable, the task
should be switched to connectedCheck to test all the build flavors

Before, it was running:

* testBasicDebugUnitTest
* testBasicReleaseUnitTest
* testFullDebugUnitTest

Since there are no Robolectric tests for only "basic", and there are no
tests specific to "release" or "debug", those three runs will be running
the same tests, except for the handful of "full" tests. So running
testFullDebugUnitTest covers all cases.

The emulator support seems to have totally melted down, so this is a step
back towards the old working setup.

This also only runs one emulator test by default, then runs 3 SDK
levels for final commits.  The single default test is the optimized
F-Droid system image included in the Docker image.

Having dynamic build config variables breaks instant APK updates:
https://developer.android.com/studio/build/optimize-your-build#use_static_build_properties

#1379

This means that we can decide whether to ignore the style tests if the
rest of the more meaningful tests pass.

This gathers all files that are not tracked by git into a named ZIP file,
which is available for 1 week to download from the Pipelines page for the
fork that ran the build.