release-26.1: sql: add distsql_prevent_partitioning_soft_limited_scans

[blathers-crl]

Backport 2/2 commits from #160051 on behalf of @michae2.

---

sql: add distsql_prevent_partitioning_soft_limited_scans

Add a setting to the physical planner which prevents partitioning of soft-limited scans, to make them match hard-limited scans. This makes them lazier.

Fixes: #160530

Release note (performance improvement): Add a new session variable, distsql_prevent_partitioning_soft_limited_scans, which, when true, prevents scans with soft limits from being planned as multiple TableReaders by the physical planner. This should decrease the initial setup costs of some fully-distributed query plans.

---

sql: enable distsql_prevent_partitioning_soft_limited_scans by default

Release note (performance improvement): enable setting distsql_prevent_partitioning_soft_limited_scans by default.

---

Release justification: low-risk performance improvement.

[blathers-crl]

Thanks for opening a backport.

Before merging, please confirm that the change does not break backwards compatibility and otherwise complies with the backport policy. Include a brief release justification in the PR description explaining why the backport is appropriate. All backports must be reviewed by the TL for the owning area. While the stricter LTS policy does not yet apply, please exercise judgment and consider gating non-critical changes behind a disabled-by-default feature flag when appropriate.

[cockroach-teamcity]

This change is 

[yuzefovich]

I'd backport both commits to 26.1 right away, but up to you.

@yuzefovich reviewed 11 files and all commit messages, and made 1 comment.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @DrewKimball, @michae2, and @mw5h).

[yuzefovich]

My argument for backporting both commits to 26.1 is the following:

• the cost of discovering a regression because of enabling it is lower on the innovation 26.1 release than on the regular 26.2 release
• more baking time on master will not expose the performance regression if it happens, and we don't have a good signal to go proactively look for it either.

[michae2]

Good arguments. It does seem lower risk to enable it in 26.1.

@michae2 reviewed 11 files and all commit messages, and made 1 comment.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @DrewKimball and @mw5h).