Add mixed raid levels #2520

[phillxnet]

Extend our existing raid levels to include:
raid1c3 and raid1c4, introduced in kernel 5.5.
Additionally add mixed raid capability.
We artificially reduce mixed raid profile options to assist with usability.

Fixes #2520

Adds abstraction, with tests, to generate a profile from our existing pool raid levels mechanism.
Includes:

• Minor rename-refactor from prior TODO.
• Enable distinguishing between single & single-dup.
• Add an "unknown" profile as fail-through catch-all.
• Enable easy Web-UI access to data/metadata via additional Pool object properties as thin PROFILE look-ups.
• Surface data-metadata in pool details Web-UI page.
• Remove now redundant single raid designator for data, if metadata = single. As we now have data-metadata surfaced we no longer need this.
• Refactor supported profiles var for test use. SUPPORTED_PROFILES was a class variable without requirement to be this way. Move to module level and use in test_pool.py unsupported profile test case.

[phillxnet]

Testing

poetry run django-admin test
.............................................................................................................................................................................................................................................................
----------------------------------------------------------------------
Ran 253 tests in 25.080s
OK

An rpm was build for both 15.3 (no EOL) and 15.4 (current) and all behaviour was as expected: within the capabilities of the respective kernels. The openSUSE Leap 15.3 default kernel does not support RAID1C34 and we get appropriate error messages surfaced accordingly when balance or new pool is attempted. But all other kernel supported raid levels were represented as before, but with data-metadata info within the Web-UI.

On our current Leap 15.4 RAID1C34 is supported and test pools were made/re-raided to the various new matched/mixed raid levels. We also now more properly report the ROOT pool as "single-dup" when that is actually the case.

Caveats

We have anomalies with regard to [EDIT size &] free space on the newer profiles. This can, and it is proposed should be, issued independently, as there is as yet little investigation into exactly where we are currently failing in this regard.

[phillxnet]

We have anomalies with regard to [EDIT size &] free space on the newer profiles.

A companion follow-up issue has been opened and linked to this pull request to address the Pool size calculation bug present in the newer raid levels introduced by this pull request.

[phillxnet]

Merging as this looks to behave as expected and we have an additional test to confirm the additional abstraction now involved in transitioning the Rockstor raid profile names (now extended) to the actual data-metadata brtrfs profile names.