Un special-case system drive btrfs-in-partition treatment

[phillxnet]

In the olden days, pre:

• "improve root not in partition behaviour and mdraid member labeling. Fixes improve root not in partition behaviour #1164" improve root not in partition behaviour and mdraid member labeling. Fixes #1164 #1166
• "enhance disk role/management subsystem. Fixes enhance disk role/management subsystem #1494" enhance disk role/management subsystem. Fixes #1494  #1622
• "support full disk luks. Fixes Support full disk LUKS #550" support full disk luks. Fixes #550 #1716

we managed only whole disk btrfs, and special cased our system drive as it was partitioned. This is no longer necessary and represents an inconsistency that adds complexity - bringing with it a maintenance burden.

It is proposed that we leverage the work in the interim years re our data dives to apply similarly to our system drive (drives in the future). With the aim of removing legacy special treatment that was originally intended solely to present a partitioned system pool member as if it was a whole disk: the only entity we understood at that time.

I.e. our low-level internal representation from system.osi.scan_disks() for the system disk is presented below.
The following are older real-system test data from when our OS pool was labelled rockstor_rockstor but otherwise similar.
Test reference:

rockstor-core/src/rockstor/system/tests/test_osi.py

Lines 1072 to 1076 in 4d60a2c

	def test_scan_disks_btrfs_in_partition(self):
	"""
	Test btrfs in partition on otherwise generic install. System disk sda
	data disk (for btrfs in partition) virtio with serial "serial-1"
	prepared as follows with regard to partition / formatting:

Disk(
                    name="/dev/sda3",
                    model="QEMU HARDDISK",
                    serial="QM00005",
                    size=7025459,
                    transport="sata",
                    vendor="ATA",
                    hctl="2:0:0:0",
                    type="part",
                    fstype="btrfs",
                    label="rockstor_rockstor",
                    uuid="355f53a4-24e1-465e-95f3-7c422898f542",
                    parted=True,
                    root=True,
                    partitions={},
                )

Where-as the equivalent btrfs-in-partition pool member would be represented as follows:

                # Note partitions entry within vda, consistent with cli prep.
                Disk(
                    name="/dev/vda",
                    model=None,
                    serial="serial-1",
                    size=4194304,
                    transport=None,
                    vendor="0x1af4",
                    hctl=None,
                    type="disk",
                    fstype="btrfs",
                    label="btrfs-in-partition",
                    uuid="55284332-af66-4ca0-9647-99d9afbe0ec5",
                    parted=True,
                    root=False,
                    partitions={"/dev/vda1": "vfat", "/dev/vda2": "btrfs"},
                )

I.e. normalise on our btrfs-in-partition internal representation and remove our now inconsistent special treatment of the system drive. So that all drives are referenced, at the scan_disk() level, by their base canonical name, not a partition reference (sda, not sda3 in above) and that the system disk, as per all data disks now, carries a partitions reference: which in turn would also normalise the parted=True reference as pertaining to the canonically named "Disk" entry.

We still have the potentially inconsistent fstype=... element: when dealing with partitioned devices, but this is consistent with our single btrfs partition per device specification/limit.

The primary aim here is to simplify our scan_disks() and normalise its output across both system and data drives. This is turn should ease ongoing maintenance (scan_disks() has excessive cyclomatic complexity) and help to accommodate future enhancements such as btrfs multi-device "ROOT" pool capability. It should also help with normalising our pool management at all higher levels in the code: given the OS pool member/s will be akin to our current data pool members.

Check list of proposed approach:

• modify all existing tests to expect the issue associated behaviour change.
• approach the functional changes in scan_disks() to return all tests to passing again.
• ensure we have accounted for and fixed the failure detailed in the 2 new tests associated with Disk miss-attribution to ROOT pool #2749 & Disk being misattributed to ROOT pool #2749 #2823
• resolve all higher-lever special cases that are now redundant.

[phillxnet]

A 'special case' element of how we currently process the root drive within scan_disks(), that significantly complicates our process, is as follows.

• For current btrfs-in-partition data (non system (root=False)) drives we hold the parent drive, i.e. sdg, as canonical and it already has, by way of lsblk most of the info we require: model & serial for example. Upon processing any of its partitions we back-port to the parent block device each partition's fstype and name.

• For current system btrfs-in-partition we do almost the opposite. We hold the partition ("/" mount), i.e. sda3 as canonical, and have to forward port (parent devices are listed first in lsblk) some of the info we require to this partition.

There are caveats here however:

• data pool members default, and are strongly encouraged to be, whole disk: unpartitioned.
• the currently singular system pool member is almost always partitioned as it is a requirement for current boot arrangements, curtousy of both legacy and uefi boot hardware.

Note that fstype, uuid info etc are held by the direct container (the partition if btrfs-in-partition), not the parent. however we still gain simplification if we treat all drives similarly.

[phillxnet]

Closing as:
Fixed by #2835