Use std page format for main forknum in neon_wallog_page

[knizhnik]

Problem

neon_wallog_page is called from neon_write/neon_extend and force wallowing of

1. FSM page
2. VN page
3. filling gap when extending relation

Only in first two cases non-standard page format is used.
Non-stadnard page format disables hole optimization.

Summary of changes

1. Remove incorrect (obsolete) comment.
2. Use std format for main fork pages which are forced wallgged.

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[github-actions]

3060 tests run: 2927 passed, 0 failed, 133 skipped (full report)

---

Flaky tests (3)

Postgres 15

• test_crafted_wal_end[last_wal_record_xlog_switch_ends_on_page_boundary]: debug

Postgres 14

• test_download_remote_layers_api: debug
• test_location_conf_churn[1]: release

Code coverage* (full report)

• functions: 31.4% (6330 of 20161 functions)
• lines: 47.3% (47715 of 100932 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
47de08b at 2024-05-11T07:18:38.115Z :recycle:}

[hlinnaka]

We don't know if the page follows the standard page layout or not. All the built-in AMs do nowadays, but there's no hard guarantee on that.

[knizhnik]

We don't know if the page follows the standard page layout or not. All the built-in AMs do nowadays, but there's no hard guarantee on that.

Right now neon_wallog_page with force=true is used only in neon_extend. Although there is also no warranty that extends is always called with zero page, currently all smgrextend callers do it.

Concerning guarantees... I searched for all usages of log_newpage with page_std=true.
And one place seems to be suspicious to me: CreateAndCopyRelationData which calls RelationCopyStorageUsingBuffer for all relation forks with page_std=true. But unless I missing something, it doesn't correctly work for VM/FSM forks because pd_upper/pd_lower are not changed for them after been initialized by PageInit (so page will be wall logged as zero page).
Isn't it a bug in Postgres?

Also there are several places where heap pages are wallogged using page_std=true (in vacuum, heap rewrite). Certainly standard heap is using standard pages. But there is heap AM now available, so in principle some extension can emit non-standard heap pages.