This enables a new capability for which support was added in Ganeti
3.0.0: postcopy-ram migration support. Enabling this flag allows Ganeti
to automatically switch to postcopy-ram when precopy-ram migration is
not completing fast, allowing us to migrate very busy machines much more
rapidly and without human intervention (eg. no need to SIGSTOP gitlab
processes when migrating gitlab-02).

https://github.com/ganeti/ganeti/blob/master/NEWS#automatic-postcopy-migration-handling-for-kvm-guests
https://wiki.qemu.org/Features/PostCopyLiveMigration

This is mostly so I can document the new ~Survey tag in GitLab.

I just upgraded a workstation to bookworm by mistake like this. Oops.

it is more readable that way

Closes team#40853

This mainly adds an upgrade howto to facilitate continuing upgrades of
this service.

This reverts commit bfd312ed.

This is a test of issue templates to see if the default templates work
and if issue templates work at all. Unless there are project
changes (which I won't do now), this should only affect the wiki
replica...

See team#29398.

An "alert" is not necessarily delivered through bots and email and
everything: it *could* be just a message on a dashboard, which is
actually a scenario I am considering.

In particular, I am considering the idea that we explicitly do *not*
want email notifications for TPA services, because those create a lot
of noise and are not necessarily useful for figuring out what's going
on (as opposed to a dashboard).

In any case, it seems important to decouple those two notions, which
were kind of mixed up before. This should be clearer now.

Requirements section modifications

See merge request !34

 1. the dsa-update-apt-status needs a TERM variable otherwise it
 sleeps for a long time

 2. we can use unattended-upgrade to DTRT most of the time

I added the "trigger service check update" here because some checks are
expensive (eg. anything to do with apt or needrestart) and we might not
be monitoring those every minute. So it should be possible to handle an
alert generated by such components and be able to quickly trigger a
check for confirmation, instead of having to wait a certain amount of
time.

As for event history, I think it's also an important item to have in
this list. When handling an incident, it's not ideal to have to rely on
IRC or email notifications generated by the system for this because each
operator may have different clients for those things with different
retention policies, so establishing a procedure for this would be
impractical if not impossible.