Summary:
Generally, an `ALTER TABLE ... ADD CONSTRAINT` may be applied to a table that has data that does not satisfy the constraint. To handle this case, the alter table code validates the constraint (see `validateForeignKeyConstraint` in `ATRewriteTables`).

This is not required in the major upgrade case, because we just link the pg15 table metadata to the same table in DocDB - all the rows already exist in the DocDB table. The pg11 table already had the constraint, so we know all rows satisfy the constraint.  Pg15 won't let us insert rows until the catalog is fully set up (including this constraint), so there's no case where this check could fail during upgrade.

We can skip this check in upgrade without impacting correctness, and this saves us a read to the old catalog.

Prior to this change, this problem manifested as a catalog version error for similar reasons as D40098 / f2b21cdebbbe and D39948 / ae4fd6b1aa29. Each of those changes stopped the pg15 code from needing to send a read request to a pg11 tserver.  This change specifically skips the `validateForeignKeyConstraint`, which required reading through the referenced table.
Jira: DB-14098

Test Plan:
```
./yb_build.sh release --cxx-test pg15_upgrade-test --gtest_filter Pg15UpgradeTest.ForeignKeyTest -n 40
```

Reviewers: fizaa, tfoucher

Reviewed By: fizaa

Subscribers: yql

Differential Revision: https://phorge.dev.yugabyte.com/D40143