[POC] Double root partition sizes in the initrd

[mtoman]

At this moment, root partition sizes are defined at build time and we have no way to resize them on running devices.

On its own, this is a nontrivial problem to solve:

• There are two root partitions, rootA and rootB, sandwiched between boot and state, so there is not enough space to grow them
• On first boot we resize the data partition to fill the whole disk, moving it around the disk to make more space is very expensive
• Though we try to avoid it, some device types do hardcode partition numbers/layout in the bootloader to implement the A/B rollback

This patch adds an initrd script that doubles the root partition sizes by doing the following:

• Shrink the data partition by 2 * original_root_size
• Move rootB to the newly reclaimed space at the end of the disk
• Expand rootB to double its original size
• Expand rootA to double its original size, using the space formerly occupied by rootB

This is obviously a one-time operation. Once rootA has eaten the space originally occupied by rootB, the same trick can't work again. It also creates ambiguity between partition layouts - newly provisioned devices with bigger partitions defined at build time will end up with a different partition layout than devices that went through the growroot procedure in the field.

We do accept this as a compromise as on some device types we need to grow the root partitions on existing devices without reprovisioning.

---

Contributor checklist

• Changes have been tested
  • Covered in automated test suite
  • Manual test case recorded
• Change-type present on at least one commit
• Signed-off-by is present
• The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

• When submitting a review, please pick:
  • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
  • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
  • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)