Never precalculate stats for LIMIT pushdown

[mwd410]

Description

This removes the ability to precalc stats for a LIMIT pushdown. I am unaware of a situation where the stats would be useful for a simple LIMIT pushdown. We could obviously make this specific to sql server only if requested, but I don't see value in this regardless.

Additional context and related issues

This came out of a complaint from a starburst customer. In SQL Server, because the statistics are gathered on a per-column basis, this causes SELECT * FROM foo LIMIT 3 to be much, much slower than SELECT * FROM foo. I attempted to improve the performance of that procedure using dm_db_stats_histogram, but this proved to not have all the same information. The only other remediation would be to not precalculate stats for LIMIT pushdown on sql server specifically, but i don't believe a simple limited table scan could possibly benefit from stats, hence this PR to remove it entirely.

Release notes

(X) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

[findepi]

This removes the ability to precalc stats for a LIMIT pushdown. I am unaware of a situation where the stats would be useful for a simple LIMIT pushdown.

Thats would be useful when LIMIT is part of bigger query, where there will be stats-based decisions later on.
I admit it's probably not the first query shape that comes to mind when thinking about a query with LIMIT.

Given that the engine has the full knowledge of the query shape, why not let the engine ignore the request to precalc stats when the engine knows the stats won't be used later on?
Or, equivalently, let the precalc be lazy.

[mwd410]

Thats would be useful when LIMIT is part of bigger query, where there will be stats-based decisions later on.

@findepi I assumed that if we pushed down both a filter and a limit, and only the filter wanted to precalc stats, that we still would use those stats - is that incorrect?

Given that the engine has the full knowledge of the query shape, why not let the engine ignore the request to precalc stats when the engine knows the stats won't be used later on?

That sounds like a reasonable plan. I'll see if I can figure that out.