fallback: Detect and break out of reboot loops

[jprvita]

The firmware on some Acer machines (and maybe others) always resets the
boot entries and BootOrder variable to what was defined in the firmware
setup program, overriding any external changes (including the changes
made by fallback).

Before shim cared about TPMs this was not a problem in practice, as
fallback would create and chain-load a boot entry for the OS on every
boot. However, since commit 431b8a2 the system is restarted if a TPM
is detected on the system, triggering an infinite reboot loop in systems
with such firmware. This is a known problem which has been previously
reported on #128

More recently, the problem has been addressed by commit a5db51a,
which presents a screen with a countdown to the user, where they can
interrupt boot and choose to have fallback always chain-load the new
entry instead of restarting the system, to break out of the reboot loop.
While this solution works, it has a few shortcomings:

1. It makes an otherwise glitch-free boot process not smooth anymore.
2. The message presented is not accessible / potentially scary for
   non-technical users: if they press a key to interrupt the boot
   process, the meaning of each option is not really clear for users
   not familiar with how shim and fallback work.
3. The whole experience is made a bit worse by the fact that after
   selecting "Continue boot" / "Always continue boot", the screen will
   remain frozen until something else draw on the framebuffer. If GRUB
   is configured to be quiet, for a glitch-free boot, this may last
   several seconds until the kernel has started and loaded the
   manufacturer logo from BGRT, which gives the impression that the
   whole boot process froze.
4. This Boot Option Restoration screen overwrites all the debug
   information printed before it is displayed, essentially neutering
   FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable
   debug without rebuilding fallback.

This commit tries to automatically detect and break out of the reboot
loop without requiring any user interaction. To achieve this, a boot
counter is stored in an EFI variable and incremented every time fallback
is about to reboot the system. If the counter ever reaches a maximum
value configurable at build time (currently default to 3), another EFI
variable is set to tell fallback to always chain-load the new entry
(FB_NO_REBOOT, to make is backwards compatible with the previous
solution). The counter is then reset when shim is started and knows it
is not going to load fallback.

Fixes: #418

Signed-off-by: João Paulo Rechi Vita [email protected]