metropolis: implement A/B updates

This implements an A/B update mechanism using two slots, A and B.
This is realized with two system partitions as well as two EFI
loaders/kernels.

The A/B system relies on two EFI loader entries. This has the advantage
that there is no preloader required, which makes the system more
reliable as well as avoiding the complexity of having an un-updatable
preloader (CoreOS has this issue where their GRUB2 crashed booting newer
kernels, sadly the issue seems lost with the migration to Fedora
CoreOS). It also means that the operator can easily override the slot
being booted via the boot loader entries. Primary disadvantage is that
it relies on EFI working somewhat to spec.

New versions are booted into only once by setting NextBoot, if the
bootup doesn't succeed, i.e. if the boot doesn't get to a cluster rejoin
the next boot will be the old slot. Once it gets to this stage the
permanent BootOrder is changed.

The EFI loaders don't know if they are slot A or B because they are
identical and relying on OptionalData in the boot entry to indicate the
slot means that if the EFI boot entries go away, recovering is very hard.
Thus the loaders look at their own file name to determine what slot they
are in. If no slot could be determined, they default to booting slot A.
It is planned to eventually use Authenticode Stamping (passing data in
fake certificates) to stamp the slot into the loader without affecting
the TPM hash logged.

Change-Id: I40de2df8ff7ff660c17d2c97f3d9eb1bd4ddf5bc
Reviewed-on: https://review.monogon.dev/c/monogon/+/1874
Tested-by: Jenkins CI
Reviewed-by: Serge Bazanski <serge@monogon.tech>
diff --git a/metropolis/proto/ext/authorization.proto b/metropolis/proto/ext/authorization.proto
index 12780f7..208e4b6 100644
--- a/metropolis/proto/ext/authorization.proto
+++ b/metropolis/proto/ext/authorization.proto
@@ -25,6 +25,7 @@
     PERMISSION_APPROVE_NODE = 4;
     PERMISSION_UPDATE_NODE_ROLES = 5;
     PERMISSION_READ_NODE_LOGS = 6;
+    PERMISSION_UPDATE_NODE = 7;
 }
 
 // Authorization policy for an RPC method. This message/API does not have the