fc272c3 fully automate repository changes

Authored and Committed by kparal 7 months ago
    fully automate repository changes
    
    This is a cherry-picked commit 1db958c4fbd16ec from the rawhide branch. The
    purpose is to have repo updates automation in *all* branches, so that we can
    massively simplify Releng's SOP docs. (If this doesn't get pushed to all
    branches, the SOPs need to document both versions).
    
    The original commit description is below:
    
    ----
    
    Instead of performing error-prone manual changes in .repo files several times
    per cycle, this patchset brings fully automated handling of such edits. All the
    releng person needs to do is to set `rawhide_release` and
    `updates_testing_enabled` variables (and of course adjust `Version` and
    `Release`), and all the repos will be auto-magically populated with the correct
    values during build (which includes `enabled=0/1` and `metadata_expire=6h/7d`).
    The intention is to avoid human errors which inevitably happen (an example [1]).
    
    This means:
    
    * Rawhide/ELN repo files will get enabled for Rawhide builds, disabled otherwise.
    * Standard repo files will get enabled for non-Rawhide builds, disabled otherwise.
    * Updates-testing repo will get enabled per specified configuration (ignored on
      Rawhide).
    * Base repo files will have short metadata expiration during development period
      ("Branched"), long expiration during stable period.
    
    Everything is covered with tests, to prevent humans and automatons from doing
    mistakes. That covers the automated changes to repo files, but also e.g. ensuring
    that updates-testing is not enabled in a Final release by mistake.
    
    Coupled with this changeset is an adjustment to certain repo files to make sure
    all the sections defined in a single repo file have the same value
    `metadata_expire=`, as it makes sense. And also in the spec file the rawhide
    subpackage description was moved next to the subpackage definition, they were
    split by mistake in the past, it seems.
    
    If this gets merged, it will massively simplify Releng's Mass Branching SOP in
    the future [2].
    
    [1] https://src.fedoraproject.org/rpms/fedora-repos/c/08819dbf9428d57eedbe5cd978b516f995bb8b6a?branch=f34
    [2] https://docs.pagure.org/releng/sop_mass_branching.html#fedora-repos
    
        
file modified
+8 -4
file modified
+4 -4
file modified
+7 -6
file modified
+7 -6
file modified
+109 -18
file modified
+1 -1
file modified
+1 -1
file modified
+1 -1
file modified
+1 -1
file modified
+4 -4