Add vacuum type to vaccum activity view

What does this MR do and why?

The current view doesn't expose the autovacuum type and because wrap prevention vacuums can block the migration process, we need a simple way to tell if the vacuum is a wraparound prevention one.

The last occurrence of this was in gitlab-com/gl-infra/production#14888 (closed) where a vacuum on ci_job_artifacts blocked the migrations and had to be reverted: !123212 (merged)

With this change we can check if it's possible to execute the migrations and only skip the ones that are blocked, like: !123355 (diffs)

How to set up and validate locally

1. Start an wraparound prevention vacuum on ci_builds:

• pgai connect ci - create and connect to a dblab thin clone
• alter table ci_builds set(autovacuum_freeze_max_age = 100000); change vacuum settings to run more frequently
• update ci_builds set finished_at = now() where id in (select id from ci_builds limit 100) \watch 0.001 run a lot of updates to trigger the vacuum in a couple of minutes

2. Execute the migrations against the thin clone: RAILS_ENV=test pgai use -o ci bin/rails db:migrate:ci
3. Open a rails console connected to the thin clone: pgai use -o ci bin/rails c -e test
4. Check the autovacuum stat records:

[17] pry(main)> Gitlab::Database::SharedModel.using_connection(Ci::Build.connection) { Gitlab::Database::PostgresAutovacuumActivity.all.wraparound_prevention.to_a }
  Gitlab::Database::PostgresAutovacuumActivity Load (272.6ms)  SELECT "postgres_autovacuum_activity".* FROM "postgres_autovacuum_activity" WHERE "postgres_autovacuum_activity"."wraparound_prevention" = TRUE /*application:console,db_config_name:ci,console_hostname:rocket-sled.local,console_username:marius,line:(pry):13:in `block in __pry__'*/
=> [#<Gitlab::Database::PostgresAutovacuumActivity:0x0000000145db6500 table_identifier: "public.ci_builds", schema: "public", table: "ci_builds", vacuum_start: Mon, 12 Jun 2023 09:33:42.596660000 UTC +00:00, wraparound_prevention: true>]

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.