Tor Connection: allow the user to retry from the error screen

Let's say we fail to connect to Tor due to an unstable Internet connection that went off briefly, then came back, like a satellite link or poor mobile Internet connectivity in the countryside. I land on the Tor Connection error screen.

In this scenario, simply retrying with the same configuration will most likely be sufficient to fix the error.

But we don't allow users to easily do this, short of restarting Tails of course: currently, on the error screen, the "Connect" button is disabled by default, until the user goes to one of the sub-screens (clock, proxy, etc.) and comes back. (At least in some cases it then becomes enabled even if the user did not do any change in the sub-screen they visited, so in practice we already have a hidden, convoluted way to retry, but that's somewhat besides the point.)

Decreasing the "sign of life" timeout on !567 (merged), from 30s to 10s, will make things worse for these user scenarios: it will increase the chances that the Internet connectivity won't recover in time to give us "sign of life" before the timeout, so these users will land on the error page more often. [Depending on the exact timing, and whether the user configured bridges or not, the timeout that matters here can be either 30s vs. 10s, or 2×30s vs. 2×10s: in some of these situations we would fall back to the default bridges and succeed, in some situations we would not fallback, in some situations we would fall back and fail.]

IMO !567 (merged) is worth it anyway, because I believe the scenarios that regress are rare, while !567 (merged) improves UX significantly for every boot in some user scenarios that seem more common and more important to our personas, such as using obfs4 East of UTC.

However, @boyska argued, and mostly convinced me, that if we do this change, then we should mitigate the impact of that regression, by making it easy for users who hit the regression to retry connecting to Tor with the exact same configuration.

Here's the design boyska proposed:

• The "Connect to Tor" button is always sensitive, as in: the user can click it and Tor Connection will try to connect.
• Until the user has visited one of the sub-screens, this button reads "Retry Connecting to Tor".
• Once the user has visited one of the sub-screens, this button reads "Connect to Tor".

I agree it is important to pay attention to the scenarios that !567 (merged) will make worse. I'm not sure this proposal is the best possible one but I mostly like it. The main drawback I see is that this encourages users to just retry, while I think most of them actually need to fix something first. Also, I'm not a fan of a button changing labels (even if the action it triggers remains the same) but that's a minor thing I suppose.

cc @sajolida