refs tails#16896

Otherwise, stats may be incorrect if mirrors.json has changed
while check-mirrors is running.

This avoids having the output polluted with:

  The following cops were added to RuboCop, but are not configured. Please set Enabled to either `true` or `false` in your `.rubocop.yml` file:
   - Layout/EmptyLinesAroundAttributeAccessor (0.83)
   - Layout/SpaceAroundMethodCallOperator (0.82)
   - [… dozens more cops …]

These new cops will be enabled in the next Rubocop major release.

For details, see https://docs.rubocop.org/rubocop/versioning.html

It would always return 0, because "bad" is in a format
that get_mirrors_weight does not expect.

GitLab CI: switch to an image that actually has Rubocop

See merge request !4

The combination of "browser, don't try to guess the file type"
and "I won't tell you what's the actual file type" does not work.

refs tails#18884

--stats is more useful if weighted

See merge request !3

this is what really matters to users: what's the probability that I will
pick a working mirror?

Array#append was introduced later.

Add --stats to check_mirrors.rb

See merge request !2

it is especially useful when you need to know the ratio of good vs bad
mirrors (happens during release process)

closes #18540

Fixes Rubocop Metrics/AbcSize offense.

On my sid system, check-mirrors.rb fails on one mirror whose web page
has invalid HTML:

    $ ./check-mirrors.rb --channel ${DIST:?} --allow-multiple --debug --fast tails-amd64-${VERSION:?} --url-prefix https://ftp.nluug.nl/os/Linux/distr/tails/tails/
    version:  tails-amd64-4.15
    fetch:    https://tails.boum.org/inc/trace
    trace:    1611584352

    mirror:   https://ftp.nluug.nl/os/Linux/distr/tails/tails/
    fetch:    https://ftp.nluug.nl/os/Linux/distr/tails/tails//project/trace
    trace:    1611584352
    fetch:    https://ftp.nluug.nl/os/Linux/distr/tails/tails//stable/
    Traceback (most recent call last):
    	7: from ./check-mirrors.rb:447:in `<main>'
    	6: from ./check-mirrors.rb:447:in `each'
    	5: from ./check-mirrors.rb:465:in `block in <main>'
    	4: from ./check-mirrors.rb:200:in `check_versions'
    	3: from ./check-mirrors.rb:187:in `scan_for_links'
    	2: from /usr/lib/ruby/vendor_ruby/nokogiri/html.rb:16:in `HTML'
    	1: from /usr/lib/ruby/vendor_ruby/nokogiri/html/document.rb:215:in `parse'
    /usr/lib/ruby/vendor_ruby/nokogiri/html/document.rb:215:in `read_memory': Parser without recover option encountered error or warning: 30:8: ERROR: Opening and ending tag mismatch: font and b (Nokogiri::XML::SyntaxError)
    zsh: exit 1     ./check-mirrors.rb --channel ${DIST:?} --allow-multiple --debug --fast

To workaround this, enable the Nokogiri RECOVER parser option,
whose documentation reads "Recover from errors":
https://nokogiri.org/rdoc/Nokogiri/XML/ParseOptions.html

By default wget has a timeout of 900 seconds for each of DNS lookup, TCP
connection, and idle time. Shortening it will make the --fast runs more
predictable in duration.

I was hesitating to put an even lower timeout to match better what the
expectation of users might be: I would probably try to restart a
download that was idle for 60 seconds.

But I'm also afraid of triggering too many fast negative.

This is preliminary work, that could be leveraged to generate a summary
file during a “first, fast run” which could be used in a “second, slow
run” to only work on mirrors that weren't already spotted as obviously
not in a good shape.

This makes it possible for the caller to figure out whether things went
fine.