Run functional tests against external server

[redshiftzero]

Description

In order to catch bugs like #2827 (where a necessary update to an Apache AppArmor profile was not done) in CI, we should run our functional test suite externally against the source and journalist interfaces. This will require a modification of the functional tests to be able to run against an external server.

Note that this depends on #1569, using Tor Browser in our functional tests such that we can run against an onion service.

User Stories

As a SecureDrop developer, I want a failure to make necessary changes to AppArmor profiles to be caught by CI so that bugs don't creep in to the develop branch.

As a SecureDrop release manager, I would like to be able to run my entire suite of functional tests against a release candidate running in VMs in order to reduce manual testing and speed up the release QA process.

[kushaldas]

Picking this up as I am already working on the Tor browser based tests.

[ghost]

using Tor Browser in our functional tests such that we can run against an onion service.

I'm not sure I understand in which case that would be useful ? The staging environment is setup exactly in the same way as the production environment as far as the app are concerned, including AppArmor. Running the functional tests against the 127.0.0.1 will find bugs like #2827 and I fail to see why going via a .onion would improve the functional tests coverage.

[kushaldas]

There are cases which can only be seen in a production instance, for example #2835. Testing against an .onion address will help us to identify these kind of corner cases.

[ghost]

So after discussions with @kushaldas and @msheiny on gitter, my understanding is that the easiest way forward would be to allow 8080 + 8081 connections to the staging in addition to the ssh port it currently has so that it can be targeted by functional tests from another machine. Trying to do the same via a .onion is going to make the functional tests extremely unreliable. A long term (and sexy) alternative would be run a local tor network and arrange for the staging to connect to it instead of the actual tor network. That would create a stable environment suitable for testing.

[msheiny]

to add to @dachary's update - we could also do an ssh tunnel from testing docker/vm --> app-staging. We'd have to toggle AllowTcpForwarding in the ssh config but i think this would more closely match the prod environment vs. punching holes on iptables.

I tend to agree with avoiding running all the tests over tor strictly because im worried about CI stability issues that will arise. We should definitely investigate running a local tor test network though long-term. Opened #2952 to track that.

[kushaldas]

If we have to just test against a local instance or something with a direct connection, my branch works well :) Will push the latest changes in the morning.

[eloquence]

Because this work is tightly coupled, I'm merging this task into epic #3659 to improve visibility. That doesn't mean the work is done; it's still WIP. I will update relevant historical tickets to link to the new epic, as well.