Upgrade Tor Browser to 10.0.14-build1

See merge request tails/tails!382

Resolve "onion-grater race condition"

Closes #18123

See merge request tails/tails!345

Retry failed upgrade downloads, reusing the previously downloaded data, and fallback to the DNS mirror pool

Closes #15875 and #17615

See merge request tails/tails!379

Upgrade tor to 0.4.5.7

Closes #18244

See merge request tails/tails!380

Currently translated at 100.0% (52 of 52 strings)

Translation: Tails/wiki/src/doc/anonymous_internet/thunderbird/openpgp_migration.*.po
Translate-URL: https://translate.tails.boum.org/projects/tails/wikisrcdocanonymous_internetthunderbirdopenpgp_migrationpo/it/

Currently translated at 98.9% (96 of 97 strings)

Tails::IUK::LWP::UserAgent::WithProgress: display correct progress status when resuming a previously failed download

Previously, when a download failed and was resumed, the progress bar started
back at 0% on every retry.

It'll need to know:

 - which temporary files we're downloading to
 - the expected total size of the download

… so it can compute the current progress status accurately, based on the total
amount of data already downloaded, while currently it only knows about the
amount of data downloaded during the current attempt, ignoring what we already
had before resuming the download.

This gives other methods than run() access to this information:
the LWP::UserAgent-based object will need it soon.

Closes #18244

Retry failed upgrade downloads, reusing the previously downloaded data, and fallback to the DNS mirror pool

This is the solution called "C + fallback DNS pool" on #15875.

Incidentally, since the SocksPort we're using has IsolateDestAddr and
IsolateDestPort, this also gives us "C + new Tor circuit" for the last retry in
most cases (that is, unless the mirror picked from mirrors.json, that we tried
to download from previously, is in the DNS pool, and we pick it again from from
the DNS pool).

This should allow the Upgrader to recover, transparently for the user, from
a number of failure modes, such as:

 - We picked a mirror that's down or flaky.
 - We picked an out-of-sync mirror that lacks the data we need to download.
 - The user's Internet connection is flaky.
 - We picked a flaky Tor circuit.

Regarding the added test scenarios:

 - For the "Successfully resuming an interrupted download, from the same mirror"
   scenario, I failed to find a simple enough way to set up a webserver that would
   fail once and then start working again, so I implemented the webserver mocking
   code directly in Tails::IUK::TargetFile::Download, which is not ideal.

 - For the "Successfully resuming an interrupted download, using the fallback
   mirror pool" scenario, I could have run a broken webserver and a functioning
   fallback one. But once I had the mocking code mentioned above, it was vastly
   simpler to just use it here as well.

refs #15875

Repair the filesystem on the system partition and avoid breaking it in the first place

Closes #17902

See merge request tails/tails!374

Currently translated at 35.0% (7 of 20 strings)

Translation: Tails/wiki/src/doc/anonymous_internet/networkmanager/no-wifi.inline.*.po
Translate-URL: https://translate.tails.boum.org/projects/tails/wikisrcdocanonymous_internetnetworkmanagerno-wifiinlinepo/es/