Page list: Use fields param for get_pages()

[rafaelgallani]

What?

Specify the fields used in the query so the page list component doesn't break for pages with a very large content.

Why?

get_pages() always selects all fields (*) - and some data isn't used when rendering the block. This breaks sites that have pages with extensive content.
We could use a direct query, but caching wouldn't be implemented. By specifying the fields param, we can specify the list of fields used in the component, andcaching gets deferred to WP_Query.

Testing Instructions

For a site with very large content on its pages, try to load/use/add the navigation block and ensure it loads correctly. It's somewhat difficult to reproduce because sometimes - in a local environment - you can meet other limits (OOM, request failing because OOM, etc), so it's more like an optimization to be able to render the block/cache the results properly so it can be used.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: rafaelgallani <rafaelgalani@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[carolinan]

Wont this break for plugins that filters get_pages()?

[rafaelgallani]

@carolinan , thanks for the review! Why would that be? Sorry, I don't get it. Are there any specific get_posts() hooks? I couldn't find any for it in the docs. I just realized you mentioned get_pages() instead of get_posts(). Sorry. That's true... 🤔
Hmm. But I still think we could benefit from the fields specified in the query. I'll try some other changes and update the PR.