28de7c7 rework the Update model (destructive changes)

Authored and Committed by kparal 2 years ago
    rework the Update model (destructive changes)
    
    Background: Initially I found out that Bodhi updates are not displayed in BBA
    for Rawhide. While working on a fix, I realized that the whole Update model is
    ... slightly weird (esp. the `status` and `pending` fields didn't reflect the
    Bodhi structures at all and were very confusing), and the fix would result in
    an increasingly hard-to-manage pile of hacks. So I instead reworked the whole
    model, trimmed unneeded stuff, made it consistent with Bodhi structures, added
    safeguards and docstrings. It had rippling effects in controller and utils
    functions, most had to be touched or rewritten. I decided to drop all updates
    from the DB during this migration, otherwise the upgrade code would get even
    more complex, and we need none of this stuff for historical purposes anyway.
    
    High-level changes:
    * `Update` now better reflects the upstream Bodhi structure, unnecessary values
      are removed
    * `sync-updates` no longer performs a useless sync for an active release with
      all its milestones inactive (a common configuration mistake)
    * Bodhi updates for Rawhide are now visible
    * The Updates view now shows all relevant updates in a single table
    * Test coverage is improved
    * All synced updates are dropped during migration and need to be synced again
    
    Models and tables:
    * add `Update.updateid` to uniquely identify an Update (instead of `title`).
      `updateid` is required to be present and has a uniqueness guarantee.
    * change `Update.status` to have the same definition as in Bodhi structs
      (incl. `pending` value). Change it to Enum and support just selected values
      which we care about (anything else shouldn't be stored in DB).
    * drop `Update.pending`, its logic was confusing and not matching Bodhi structs
    * change `Update.request` also to Enum (support all possible values)
    * drop `Update.date_*` except for `date_submitted`. The other values are not
      important, we don't need to store them.
    * drop `Update.milestones`. It was a relationship which was re-calculated on
      each Update update, it was slightly confusing (Bodhi updates are not related
      to milestones) and served only as a way to simplify certain queries. Because
      there are just a couple of those queries, I opted for model simplification
      and readjusted those queries instead. This also means "update_milestones"
      table got dropped.
    * make many Update fields `nullable=False` to ensure data consistency
    * make some Update constructor values optional. Esp. nullable columns are not
      necessary to provide. Reorder the call params order and also the attribute
      order in the class, roughly by importance, optional ones last.
    * add a primary key over both columns in "update_fixes" table, that ensures we
      don't get a duplicate entry
    * add `Bug.is_proposed_accepted`, which allows to massively simplify certain
      queries
    
    Controllers:
    * rewrite affected `controllers/` functions with the new Update model in mind
    * rename some controller functions to better indicate their purpose
    * instead of `get_milestone_pending_stable_updates()` and
      `get_milestone_updates_testing()`, which seemed to be providing little value
      in this separation, create `get_milestone_updates()` which lists all relevant
      updates and display that in the Update view
    * remove a never used `display_updates_need_testing()` controller function
    
    Views/templates:
    * changed template filter `updatelabel()` into `updatestatus()`, which displays
      Update's current status and request in a pretty way (same as in Bodhi). Used
      it then across all related views (bug list, updates).
    * in a similar fashion, display `updateid` as a fallback when `title` is not
      defined for an Update in all related views.
    * in bug list view, indicate if there are multiple related updates (and not just
      one)
    * in update list view, show a list of all "relevant" updates, instead of
      splitting it into two categories (which don't even cover everything
      important). For each update, show components for each bug tracked, not just
      the first one.
    * in blocker list view, swap Updates and Review columns to make the columns look
      better aligned
    * fixed a bug in `updatetype()` which was not aware of accepted0day/prevrel
      blockers
    
    Utils:
    * rewrite `update_sync.py`. `extract_information()` is extremely simplified due
      to model changes. `get_update()` is removed because nobody used it.
      `search_updates()` now searches in containers as well, only searches for
      updates with a supported `status`, and has better error checking.
      `get_release_bugs()` is fixed to not return rejected bugs. `sync_updates()`
      and `sync_bug_updates()` and merged into `sync_updates()` and has better error
      checking.
    
    Merges: https://pagure.io/fedora-qa/blockerbugs/pull-request/203
    
        
file modified
+50 -33
file modified
+68 -92
file modified
+32 -1
file modified
+93 -54
file modified
+137 -154
file modified
+15 -14
file modified
+105 -87
file added
+87
file modified
+17 -16
file modified
+85 -32