Implement migration skipping when `RestrictGitlabSchema` is used

What does this MR do and why?

It does use information of database_tasks: false to know that such connections are being shared with main: (a primary connection).

Such migrations even if two connections are present will be run on top of main: connection. This does solve migrations skipping/restrict approach since:

1. If database_tasks: true is used, the migration will be run everywhere, but some with restrict* will be skipped (a message will be printed, and they will be marked via schema_migrations as run)
2. If database_tasks: false is used, the migration will be run only on main:, since no db:migrate:ci will exist. Such migration will not be skipped, and instead it will be run in-order on top of main:

This does enforce usage of gitlab:db:validate_config in production to ensure that if migrations are skipped are actually correctly skipped.

Related:

• Add `gitlab:db:validate_config` to ensure the p... (!83118 - merged) should be merged first as it ensures correct configuration is used
• Support `database_tasks:` for database configur... (#356009 - closed): uses database_tasks: false approach
• Skip migrations depending on execution context (#355014 - closed): solves the migration/skipping problem by implementing Solution 2
• Support database migrations via `db/migrate` to... (#342378 - closed): is part of the an issue to support migrations when configured decomposed

Those MRs needs to be merged before this one can be:

• Expose `db_database_tasks` attribute (omnibus-gitlab!5982 - merged)
• Add `databaseTasks: boolean` to `gitlab.psql.` ... (gitlab-org/charts/gitlab!2450 - merged)
• Add `gitlab:db:validate_config` to ensure the p... (!83118 - merged)

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.