Summary:
YSQL indices have a boolean state in pg catalog indicating whether the index can be relied on to serve reads or not. When the index is first created, it is initially invalid, and the state is updated later.
In case of creating a backup, ysql_dump does not include invalid indices in the dump sql output.
However, the created snapshot includes all the DocDB tables in the snapshot, including the indices and regardless of whether or not they are valid.

This leads to creating a backup that will fail at restore with the following error:

```
[m-1] W1016 18:15:52.951835 74817 catalog_manager_ext.cc:2189] Did not find a corresponding table at restore side for the table 000034d4000030008000000000004005 from backup.
```

This is because the DocDB table with id `000034d4000030008000000000004005` corresponds to the invalid index that hasn't been included in the dump from the backup side.
It is worth mentioning that the restore only fails with the new backup workflow, where we support backups during DDLs.
The old workflow deals correctly with importing DocDB tables that corresponds to invalid indices by ignoring them at `import_snapshot` phase.

The diff fixes the issue by skipping the DocDB tables that correspond to invalid indices at `export_snapshot` phase.
The check of whether the index is valid or not happens by reading the pg catalog as of the consistent `snapshot_ht`.
Jira: DB-18732

Test Plan:
./yb_build.sh release --cxx-test tools_yb-backup-cross-feature-test --gtest_filter CrossColocationTests/YBBackupCrossColocation.TestYSQLRestoreWithInvalidIndex/0

./yb_build.sh release --cxx-test tools_yb-backup-cross-feature-test --gtest_filter TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterFailedRewrite/0

Reviewers: asrivastava, zdrudi

Reviewed By: asrivastava

Subscribers: ybase, hsunder

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