Instead of the caller having to deal with it in each instance.

We run this step twice, so without this we needlessly get a new one
the second time.

Preemptive robustness++

Refs: #12371

We replace the onion keyserver we actually use in Tails with an onion
server we run on Chutney, that redirects all TCP traffic to a clearnet
keyserver.

Will-fix: #12211

... after the gpg2 migration.

Fix-committed: #12068

We need to save the manner we started Seahorse in in a greater scope
(hence the class variable).

Will-fix: #10782

* Ruby doesn't support keyword arguments when calling; for a method
  defined as f(x = y), calling it with f(x = z) will actually create a
  local variable x in the scope f was called from.

* Since we only care whether withgpgapplet is nil or not, we don't
  have to reintroduce @withgpgapplet with the same property.

If we don't monitor whether the key has been fetched with the gpg CLI
tool we can move to the next step which used to check whether the key is
in the keyring. By that time it's too late to retry fetching.

Instead let's check with `gpg` for the key. If the key is not in the
keyring within two minutes we'll fail the step, force a new tor circuit,
and try retrieving the key again.

Since all of the gpg operations will retry after forcing a new Tor
circuit, by the time we reach the step that checks whether the key is in
the keyring the key should be there. We'll gain nothing from waiting two
additional minutes.

During my testing I found that it seems that if we're going to get a
successful result it'll happen by the time two minutes have passed.

If the key retrieval neither succeeds nor fails within 2 minutes we'll
terminate the running gnupg process, force a new Tor circuit, and try
fetching again.

Gedit no longer has a menu bar at the top of its window, causing this
feature to be broken..

We'll also keep track of how Seahorse was opened in case we need to
restart it during the test suite.

Doing this will allow this variable to be used in the Seahorse
keysyncing steps.

We're going to end up restarting Seahorse on segfault. While doing lots
of testing for #9791 I'm fairly confident that I've figured out
Seahorse's failure modes and when it'll segfault. allowing code to be
simplified.

There's some code simplification too, and the removal of the
@new_circuit_tries counter, which is all over the place and is a bit
hard to keep track of.

Also for the wget/whois test we do not try to detect if Tor was the
problem and only force a new circuit (and hence count it as a retry),
since that could lead to an infinite loop. With the new helper, we
always do MAX_NEW_TOR_CIRCUIT_RETRIES number of retries.

... and pave the way for adding more options than the user to execute
the command as.

Will-fix: #9518