Tail space reclamation issue

Due to a variety of issues (Subiquity's lack of support for virtual block devices as installation target, Ubiquity's shenanigans with ZFS devices), the installer creates a temporary partition to install the O/S, then copies it to the filesystem in the root pool.

Previously, if the user chose not to leave any tail space (or to leave less than that required for the temporary O/S installation), the ZFS installer attempted to reclaim the space.

While the reclamation works on paper (ZFS should be able to extend without problems), in practice, there is a minority of setups where this didn't work. Unfortunately, such cases typically (=always) can't be reproduced locally, and are very hard (=practically impossible) to debug. I've also asked on the official ZFS mailing list, but got no (direct) answers.

Therefore, the new strategy is:

• not doing anything if the user chooses a tail space greater than the required temporary O/S installation;
• leaving the tail space as is, if it's less than required.

Users can still claim the space after the installation; the procedure is actually simple (run from a live media):

zpool export rpool

# If on multiple disks, repeat for each disk.
#
parted -s /path/to/disk_dev rm 4
parted -s /path/to/disk_dev unit s resizepart 3 -- 100%

zpool import -l rpool

References

• Issues: #157 and #104.
• Subiquity virtual block devices support feature request
• There was also a bug (reported on Launchpad) with Ubiquity messing with the ZFS devices
• Question on the ZFS mailing list