[LKB-5974][PG_17] Add the ability to reduce FPI

[yananxin]

Context

Why is a full page image(FPI) unnecessary in Lakebase/Neon?

In vanilla PostgreSQL, full-page images (FPIs) are required to guard against torn page writes caused by non-atomic 8 KB page writes to local storage.
However, in the Lakehouse/Neon architecture, FPIs are generally not needed because the compute node never overwrites pages in place. Instead, all modifications are logged as WAL records and sent to the pageserver, which appends them into the storage layer’s log-structured layout. Since there is no local data-file page overwriting, the torn-page risk that FPIs protect against does not exist on the compute node’s local storage.

Why do we want to reduce the full page image?

Full-page images amplify every small update into an 8 KB WAL write, which drives up WAL volume and causes Reverse ETL ingestion to hit the max_wal_rate limit in Serverless Lakebase.

Why not eliminate full-page images entirely?
Full-page images help the pageserver reduce read-path I/O by providing complete page snapshots that can be used during page reconstruction. Removing FPIs entirely could negatively impact read performance.

Summary

This PR(along with the hadron PR: https://github.com/databricks-eng/hadron/pull/3155 )implements reducing FPI to improve write performance for data ingestion workloads, specifically reverse ETL and Spark streaming use cases. The feature is opt-in per table to avoid unintended impact on other customers.

Performance Impact

Testing shows 3.75x write throughput improvement without significantly impacting read performance. See performance analysis.

Major changes

Probabilistic reducing FPI generation to 5%

Added neon_should_suppress_fpi which will randomly determine if we should suppress FPI with a default value of 5%. The 5% is chosen to:

• Significantly reducing WAL volume to avoid write-amplification bottlenecks.
• Retaining a small number of FPIs so the pageserver still benefits from occasional full-page snapshots, helping maintain efficient read-path performance.

[mmeent-databricks]

Minor improvements possible, but generally LGTM.

PS. Don't forget to squash your commits before merging!