follow-up of my proposal for an alternative fix of team#40775
which does not require partitioning the LUN from outside the instance
itself

I was kind of scared of destroying everything by using fdisk. Turns
out there's a really easy hack with sfdisk.

This hack was found on this page:

https://karelzak.blogspot.com/2015/05/resize-by-sfdisk.html

This was used to resize vineale, see team#40778.

Every time I ran that, the file was already gone. I think it gets
cleared out on reboot. We may want to recreate it elsewhere, but i'm
not sure it's worth the trouble.

See tpo/core/tor#40615, thanks @jim!

We were refering to web-chi-03 which is nice because it gave us a hint
on how to fix this broken procedure, but it's too risky to have that
there, because we could recreate the VM or otherwise mess with its
configuration.

It's more likely that the primary will have the partitions setup correctly.

We were missing two crucial steps:

 1. the partitions had to be created *before* the device was passed to
    the VM, otherwise it gets completely confused and just creates one
    gigantic filesystem

 2. each partition needs to be adopted separately

Closes: team#40775.

changes merged in tpa-rfc-2 through !29

TPA-RFC-28: alphabetical triage

See merge request !29

The blockchain-less procedure didn't work: NBXplorer was stuck and
would have seemingly never synchronized. This procedure actually
worked in the end, by doing a full rsync.

See team#33750

see nextcloud#6

also regroup issues by type now that this list is growing a bit large

We probably need a clearer workflow for this, but it seems clear to me
those don't need to stay "standard" forever...

Closes: team#33949

Under bullseye the old command aborts with: "Failed to reload
local-fs.target: Job type reload is not applicable for unit
local-fs.target."

The restart operation seems to work, and the new .mount unit is created
as expected.

-l and -L are easy to confuse, just use --size here