release-24.3: sql: fix including all related FK tables into the stmt bundle

[blathers-crl]

Backport 1/1 commits from #137738 on behalf of @yuzefovich.

/cc @cockroachdb/release

---

Earlier this year in 084a741 we made a change to include all tables referencing the table from the stmt bundle (i.e. those that we have an inbound FK relationship with). However, we forgot to include tables that the referencing table is dependent on, so this commit fixes that oversight. Namely, we now include all tables that we reference or that reference us via the FK relationship, and this rule is applied recursively to every table in consideration. (Previously, we didn't include inbound FKs when handling an outbound FK nor outbound FKs when handling an inbound FK.)

Note that I believe we could have avoided including referencing tables (i.e. with an inbound FK relationship) that only have NO ACTION or RESTRICT actions in the ON DELETE and ON UPDATE, but I think those cases aren't very common, and it's unlikely to hurt including all "related" tables. The case of FK cycles is still not handled correctly on the stmt bundle recreation, but I think we have yet to run into one in a support ticket.

Informs: https://github.com/cockroachlabs/support/issues/3146.
Epic: None

Release note: None

---

Release justification: low-risk supportability improvement.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Backports should only be created for serious
  issues or test-only changes.
• Backports should not break backwards-compatibility.
• Backports should change as little code as possible.
• Backports should not change on-disk formats or node communication protocols.
• Backports should not add new functionality (except as defined
  here).
• Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
• All backports must be reviewed by the owning areas TL. For more information as to how that review should be conducted, please consult the backport
  policy.

If your backport adds new functionality, please ensure that the following additional criteria are satisfied:

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
• Your backport must be accompanied by a post to the appropriate Slack
  channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

[cockroach-teamcity]

This change is 

[rytaft]

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner)