This was not working for 2 reasons:

1. The YML file URL was pointing to the HTML version and was not
   returning valid YML. It's been updated to the raw path now.
2. The YML from this URL contains more keys than just `version` and
   `date` so we needed to ignore those other keys when constructing our
   `Struct`

Otherwise, we are seeing the following exception on Ruby 3.0:

    Failure/Error: actual_changes = keep.each_change(&:itself)
     ArgumentError:
       unknown keyword: :permitted_classes

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

This brings this keep up to date with the new housekeeper APIs.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Previously we were determining the gitlab_schema from the `table_name`.
This is causing problems as we're migrating lots of tables to
`gitlab_main_cell`. But the `gitlab_schema` must exactly match whatever
schema was used to queue the batched background migration (see
https://docs.gitlab.com/ee/development/database/batched_background_migrations.html#finalize-a-batched-background-migration
) . As such we've extracted this value from the migration record in the
database which should always be the expected value.

This `-r keeps/...` is proving to be unnecessary and likely it's fine to
just always load all the files in `keeps/*.rb`.

I considered the possibility of loading everything in `keeps/*.rb` as
well as keeping the option around in case someone wanted to manually
load a keep that was in a different directory but I couldn't think of
any good reason to do that. So to simplify the options I've just removed
it.

This will be used by Keeps to determine which group is responsible
for a given feature category, which allows a suitable (backend)
reviewer to be selected.

This is not picked up by keeps/overdue_finalize_background_migration.rb
because it is grepping for `MIGRATION =`. That is the standard way that
it's generated and documented and this was the only occurence so I
figured I'd just fix this rather than making the keep more flexible.

This adds the `gitlab-housekeeper-authored` label to all MRs and ensures
the commit message and MR always have the housekeeper link included so
that we don't need to add that manually in the keeps anymore.

It also adds some `purple` color to the dry-run output for the titles. This
makes them easier to read.

This was followup feedback extracted in
https://gitlab.com/gitlab-org/gitlab/-/issues/435618 for
`gitlab-housekeeper`.

The original implementation of `gitlab-housekeeper` can be found in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139492 and it is a
local developer tool for automatically generating merge requests for
repetitive tasks like finalizing batched background migrations. It is a
gem you can run from the command line and is being actively developed to
eventually run as a periodic job to save us from many manual repetitive
MRs.