Improve fs-resize, fix delay and simplify

[mglae]

fs-resize running at early boot time may need minutes to complete because the kernel RNG is not initialized.

When parted and sgdisk call uuid_generate(), util-linux libuuid implementation use a blocking getrandom() syscall. It waits until the kernel crng has collected enough entropy. Having a SSD, no network, no user input and no HW RNG this can take a long time. The behavior explains the delay seen in #2957.

This is fixed in util-linux 2.32:

commit a9cf659e0508c1f56813a7d74c64f67bbc962538
Author: Carlo Caione <carlo@endlessm.com>
Date:   Mon Mar 19 10:31:07 2018 +0000

    lib/randutils: Do not block on getrandom()
    
    In Endless we have hit a problem when using 'sfdisk' on the really first
    boot to automatically expand the rootfs partition. On this platform
    'sfdisk' is blocking on getrandom() because not enough random bytes are
    available. This is an ARM platform without a hwrng.
    
    We fix this passing GRND_NONBLOCK to getrandom(). 'sfdisk' will use the
    best entropy it has available and fallback only as necessary.
    
    Signed-off-by: Carlo Caione <carlo@endlessm.com>

Using parted's 3.2 'resizepart' command removes the partition recreation hack.

[MilhouseVH]

Might as well make this one Checking file system... " to be consistent?

Cosmetic nit: Would it be possible to vertically align the spinner outputs (add extra spaces after ... where necessary)?

Thanks for this, certainly is simplified, but will need thorough testing! :)

[mglae]

Looks better now :)

[mglae]

I've tested on generic only. To look for anomalies better use the fs-resize debug version.

[MilhouseVH]

After #3035 this now requires a rebase.