Introduce local staging of packages for Redfish subcloud installation

[Eric MacDonald]

The current Redfish installation process for subclouds copies the RPM packages from the system controller twice. Once by Anaconda for packages installation and a second time for feed, patching and updates directory setup for system node installation. Package transfer alone can be over 2GB of data.

Please improve the Redfish subcloud install process so that the 2G of packages is copied only once.

Severity:
---------
Minor ; this is a performance improvement request

Steps to Reproduce
------------------
Perform a Redfish subcloud install

Expected Behavior
------------------
Desired behavior would be to copy the CentOS RPM packages from system controller only once.

Actual Behavior
----------------
CentOS RPM packages are copied twice.

Reproducibility
---------------
100% reproducible

System Configuration
--------------------
Redfish Subcloud Install of system controller-0 for AIO or Standard system types

Branch/Pull Time/Commit
-----------------------
All at time of issue creation

Last Pass
---------
N/A

Timestamp/Logs
--------------
/var/www/var/log/lighttpd-access.log file to see the 2 fetch blocks during redfish subcloud install

Test Activity
-------------
Performance Testing

Workaround
----------
Prestage subcloud installation with ISO or Packages/repodata content

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/starlingx/metal/+/840210

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/starlingx/metal/+/840210
Committed: https://opendev.org/starlingx/metal/commit/1a6fd50e2c1ab2f7f78b0b44659394dce344cb76
Submitter: "Zuul (22348)"
Branch: master

commit 1a6fd50e2c1ab2f7f78b0b44659394dce344cb76
Author: emacdona <email address hidden>
Date: Mon May 2 11:26:27 2022 -0400

    Support Redfish subcloud install with single packages fetch

    This update modifies the miniboot kickstart so rpm Packages
    repodata and patches are fetched from the system controller
    only once during a Redfish subcloud install.

    The existing packages mirror operation done in the %post phase
    is moved to the %pre phase. However, since the in-service feed
    dir does not exist at that time, the fetched content is
    staged to /mnt/install/repo as

        /mnt/install/repo/Packages
        /mnt/install/repo/repodata
        /mnt/install/repo/patches

    The %post phase fetch code that was moved is replaced with code
    that positions the %pre fetched content to the local filesystem
    here:

        # feed directory
        /var/www/pages/feed/rel-xx.xx/Packages
        /var/www/pages/feed/rel-xx.xx/repodata

        # updates directory
        /var/www/pages/updates/rel-xx.xx/Packages
        /var/www/pages/updates/rel-xx.xx/repodata

        # patching directory
        /opt/patching/packages
        /opt/patching/metadata

    The miniboot kickstart is updated with a detailed description of
    the various staging/prestaging install options along with logging
    enhancements that show the source and destination flow of
    packages, repodata and patches in the installation process.

    Also modified kickstart to ensure that Prestaged Content takes
    precedence over prestaged ISO. Both of which take precedence over
    Staged Install.

    Moved Prestaged content check to %pre stage som that the next
    priority install option can be taken rather than a belated
    install failure.

    Test Plan

    PASS: Verify single packages pull over subcloud controller-0 install
    PASS: Verify with both UEFI and BIOS across various servers
    PASS: Verify end-to-end subcloud installs (60+)

    Packages

    PASS: Verify install time is shorter
    PASS: Compare feed directory before/after install
    PASS: Compare package/repodata data transfer before/after install

    Patch Handling

    PASS: Compare patched content before/after installed subcloud
    PASS: Verify patched updates are mirrored and auto applied
    PASS: Verify patches can be applied and remove after install
    PASS: Verify patch handling for both prestaged iso committed
          patches as well as non-committed patches.
    PASS: Verify patch handling when installing subclouds from a system
          controller that has committed patches for all 3 install cases.

    Failure Handling

    PASS: Verify staging feed failure leads to installation
          failure ; parity behavior
    PASS: Verify handling of failed lighttpd during packages download
    PASS: Verify report_post_failure change handling

    Robustness

    PASS: Verify in...