Move to Gitlab CI

Hans from The Guardian Project created #32193 (closed), which have a ton of useful targets in it, but I think we need to achieve two things with this move:

1. Move to Gitlab CI, such that we can drop Travis CI and AppVeyor.
2. Learn enough about Gitlab CI such that members of the Network Team are able to debug and fix things quickly when issues arises.

I suggest we split this into a couple of phases that we can update as we progress.

Phase 1

The goal here is to get something to work that we can iterate on.

• Get Tor's Gitlab instance to start a pipeline on a Debian Buster image with ./configure, make and make check. We already have a Travis CI that largest does all of that, so this one should be easy.

Phase 2

The goal here is to be able to drop Linux builders from our Travis setup.

• Move over Linux targets from Travis CI to Gitlab CI such that we have feature parity with what we have today with Travis CI.
  • test-network-all
  • test-network-all (including IPv6)
  • all-bugs-are-fatal
  • disable-module-relay
  • disable-module-dirauth
  • rust
  • NSS
  • coverage

Phase 2.5

Continue to extend the Travis CI files with additional targets up to the point where we think we get a lot out of it in the time we our CI to take. We have historically dropped builds because the sum of the time it takes to do all the builds was too large.

• Fedora support.
• Ubuntu support.

Phase 3

• Get Android builders from #32193 (closed) incorporated.

Phase N

• Get Windows builders to work such that we can drop our AppVeyor setup.
  • Include 32-bit if possible
• Get Mac OS builders to work such that we can drop our Travis CI setup.
• Get the FreeBSD, OpenBSD, and NetBSD builders (maybe only run those daily via cron?)
• Different debian/fedora versions etc
• Something with libressl
• Different openssl versions
• Different compiler versions
• fuzz-static-testcases