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.

the condition also excludes merge requests, as before

accounts, not only those in groups

and not hardcoded fleet-wide, eg. we may accept more latency for
metrics-based endpoints with java-backends than static websites

and not only offer a view of what's going on

and not only at provisioning

Add submission server instructions for exim

See merge request !33

Turns out there's a privilege we can give the user that completely
removes the need for that silly view stuff.

The basic idea would be that the Common folder is accessible to all NC
accounts: be it the general community, tor-internal, or whatever scope
the NC account policy ends up to be as discussed in tpo/tpa/nextcloud#10

see: tpo/tpa/team#40472