Consider including git for /boot and root fs integrity and changes reporting

Nobody has claimed this yet.

> Testing on top of qemu TCG with debian-12. Nonetheless to say, hashing on qemu TCG is turtle slow unfortunately but I do not see anything wrong.

> ```
> [ 70.903225] DEBUG: Root filesystem on /dev/vda3 lacks one of the configured directories: bin boot lib sbin usr
> [ 70.931377] TRACE: /bin/root-hashes-gui.sh(348): open_root_device
> [ 70.963936] TRACE: /bin/root-hashes-gui.sh(264): open_root_device_no_clean_up
> [ 71.001640] TRACE: /bin/root-hashes-gui.sh(232): open_block_device_layers
> [ 71.096543] TRACE: /bin/root-hashes-gui.sh(208): open_block_device_luks
> [ 81.971501] TRACE: /bin/root-hashes-gui.sh(232): open_block_device_layers
> [ 82.055642] TRACE: /bin/root-hashes-gui.sh(164): find_lvm_vg_name
> [ 82.279813] TRACE: /bin/root-hashes-gui.sh(187): open_block_device_lvm
> [ 82.476602] TRACE: /bin/root-hashes-gui.sh(232): open_block_device_layers
> [ 82.570460] TRACE: /bin/root-hashes-gui.sh(164): find_lvm_vg_name
> [ 82.751002] DEBUG: Did not detect an LVM2 PV: /dev/mapper/vgubuntu-root
> [ 82.822510] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
> [ 82.924851] EXT4-fs (vda3): re-mounted. Opts: (null)
> [ 1296.068011] EXT4-fs (vda3): re-mounted. Opts: (null)
> [ 1296.152712] TRACE: Under /etc/functions:update_checksums
>
> ```

> 1996-82=1214 seconds = **20.2333 minutes**
>Even if qemu TCG is not representative of real time performances, it shows computation weight of such process to hash root filesystem with default partitions, and shows a profound inneffectiveness, even if sound, process.

> I keep having the same insight/intuition over and over about having a minimal git binary to not only detect and report on files changed, but also being able to report on what changed inside of those text files. It's more food for thought then anything else here.

> A .git for /boot would be growing in time but nothing compared to root filesystem changes, and hashing its filesystem content would eventually become exponentially big to hash again from Heads, falling in the same pit. A hack around that could be to create a raw loop file for .git irectory, stored under /boot and that file only being hashed instead of .git directory content. That loop file, mounted and applied on top of tmpfs/ramfs at boot and replacing the current /boot / checks which I think would be faster.

> Could even be a thin LVM at this point that would grow in time with usage, where git repo could also be wiped and recreated at moment of detach signing /boot content, with the sole purpose of actually tracking filesystem changes and report on them since they were detached signed. That might be more efficient then hashing whole filesystems.
@JonathonHall-Purism good food for thought?

_Originally posted by @tlaurion in https://github.com/linuxboot/heads/issues/1586#issuecomment-1921869907_

Start by reading /bin/root-hashes-gui.sh and the update_checksums entry in /etc/functions, then review how /boot and the root filesystem are currently checked. The issue discusses Git-based change reporting and alternative storage approaches, but it does not define a concrete implementation or what completion should look like.

Written by the indexing model from the issue text.