Containerized import: optional full drop/recreate restore (full_postgres_cleanup)

[lucas-benedito]

Summary

Containerized import currently restores into the existing database in place
(pg_restore --clean --if-exists --no-owner -d <db>), matching the OCP
import path. This avoids needing PostgreSQL admin/superuser credentials at
all, but carries a real tradeoff: --clean only drops objects that are
present in the dump before recreating them. Any table, index, function,
or other object that exists on the live target but isn't part of the
exported artifact (leftover from a hotfix, a manually added index, a
partially-applied migration) survives the restore untouched.

A full DROP DATABASE + recreate (pg_restore --create ... -d template1)
gives a byte-clean slate matching only the dump, at the cost of requiring
real PostgreSQL admin/superuser credentials (to grant/revoke CREATEDB on
the restore user) - credentials the collection has no reliable way to
discover for external database topologies (there's currently an
undocumented, undefaulted postgresql_admin_password variable that's
silently sourced from whatever the containerized installer's own
vars_secret.yml happens to define for the local managed postgres admin
password - correct by coincidence for collocated/managed DB, wrong for
external DB).

Proposed Enhancement

Add an explicit opt-in flag, e.g. full_postgres_cleanup (default
false), that switches containerized restore to the drop/recreate
strategy:

full_postgres_cleanup: false

When full_postgres_cleanup: true:

• Require postgresql_admin_password to be explicitly set (fail fast with
  a clear message if it isn't - don't silently fall back to a
  possibly-wrong value).
• Use pg_restore --create --clean --if-exists -d template1 (the
  drop/recreate approach), with the existing Grant/Revoke CREATEDB
  bracketing.

When full_postgres_cleanup: false (default):

• Keep the current in-place restore (--no-owner, no --create, no admin
  credentials needed) - this remains the default so containerized import
  keeps working out of the box for the common case.

This lets operators who know their target's real admin credentials opt
into a guaranteed-clean restore, while everyone else keeps the
zero-extra-credentials default that already works today.

Source/Target Platform

Containerized

AAP Version

2.6

Additional Context

Surfaced during live containerized import testing on
feat/integrate-containerized-import-100-101-103 while fixing a DROP DATABASE ... is being accessed by other users race (no longer applicable
once restore moved to the in-place --clean --no-owner approach) - see the
containerized restore rework in that branch's history for the full
before/after context.