We keep hitting rate limits, and markdownlint is in debian since
bookworm-backports, so we should be safe.

This is going to be a bit slower as we need to install the package,
but it seems like a minor tweak. If this becomes a problem, we could
make a linter image that ships stuff like mdl and codespell.

This is causing locale problems that I can't reproduce locally, but
that still exist, so let's just silence this for now.

Example:

https://gitlab.torproject.org/tpo/tpa/wiki-replica/-/jobs/687276

Excerpt:

$ ./bin/mdl-wrapper $(cat changed-files.txt)
checking file service/donate.md...
/usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl/doc.rb:39:in `split': invalid byte sequence in US-ASCII (ArgumentError)
	from /usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl/doc.rb:39:in `initialize'
	from /usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl/doc.rb:50:in `new'
	from /usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl/doc.rb:50:in `new_from_file'
	from /usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl.rb:91:in `block in run'
	from /usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl.rb:83:in `each'
	from /usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl.rb:83:in `run'
	from /usr/share/rubygems-integration/all/gems/mdl-0.13.0/bin/mdl:10:in `<top (required)>'
	from /usr/bin/mdl:25:in `load'
	from /usr/bin/mdl:25:in `<main>'

This reverts commit 3b2ba6cb.

Boom:

/usr/share/rubygems-integration/all/gems/mdl-0.13.0/lib/mdl/doc.rb:39:in `split': invalid byte sequence in US-ASCII (ArgumentError)

According to iconv, that's:

$ iconv -f ascii -t utf-8 howto/postgresql.md > /dev/null
iconv: illegal input sequence at position 41113

Which is the "bullet" ("●", U+25CF BLACK CIRCLE) in the systemctl
output.

https://gitlab.torproject.org/tpo/tpa/base-images/-/jobs/683968 ran
correctly, but the image was unchanged so the new tag didn't make it.

We'd use our own image here, but i can't find a stable-backports image (base-images#13).

This will reduce the impact on Docker hub rate limiting and improve
our supply chain, among many other things.

Looks like TPA-RFC-66 is not linked anywhere, let's see if we have
gaps too!

those jobs don't need the fail-on-desync-wiki job to finish, to be able to
function

also check required variables for find-files job

this job should work with both merge requests and regular commits

There's currently 176 spelling errors in the wiki, and there were some
in this very file (`service/documentation.md`), but I've fixed those
so CI passes here.

This also required (I think) renaming the `test` job to `mdlint`
otherwise we would be somewhat incoherent: the spell check job is also
a "test" job...

I'm not sure why this works, but it does:

https://gitlab.torproject.org/tpo/tpa/wiki-replica/-/pipelines/54488

Maybe the problem is the newer alpine images don't ship bash. I'm not
sure why we were using bash in the first place; i don't believe we had
any bashism. But according to:

https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#override-the-entrypoint-of-an-image

... just an empty entrypoint is actually the way to go here.

the condition also excludes merge requests, as before

It seems we were actually never running this job, which should have
help with issues like #1. Assuming the mirror
would have been correctly configured, this job would have warned about
the desync commits.

Before the fix, of course, it wouldn't have detected anything, because
the commits were crushed, but now this should correctly fail.

We'd this in MRs CI:

    /bin/bash: line 131: git: command not found

Doh.

The comments were misrefering to things

This is necessarily going to fail.

This will make sure it will run on every pipeline, but also make
failures clearer.

This hides the actual command ran, so it's not so great.

This reverts commit a9d3ae77.

colons are a pain in the back in YAML, but it seems like the "Block
Scaler Style" works around the problem.