Comments Blocks Warnings: Add buttons to resolve warnings

[ockham]

Based on #40563 (comment) and #40563 (comment).

The Comments Query Loop block (soon to be renamed to just "Comments") and its child blocks currently use the <Warning /> component in a few places, in order to indicate that what the user will see on the frontend might not match their expectations, e.g. if comments are not enabled for the entire site, the current post (or page), or the corresponding post type.

While it's debatable whether or not the <Warning /> component is the best fit here, that's for another issue.

However, regardless of how we preset this information to the user, it'd be better if we actually gave them the agency to change whatever is preventing the Comments Query Loop (or part of it) to show up on the frontend. I.e. if comments are disabled for a post or page with a certain ID, we could add a button to enable them; or if they're disabled for an entire post type, we could add a button that either enables them right away, or at least takes them to the relevant settings screen.

(It's much less frustrating for a user if they're presented with a problem and a potential solution, rather than just the problem, and they're on their own to figure out the solution.)

FWIW, the <Warning /> components supports adding primary and secondary actions: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/warning/README.md

As seen in BlockInvalidWarning:

As seen in withMultipleValidation:

Where possible, we should add one primary button per warning that will immediately change the setting such that the corresponding part of the block will be displayed on the frontend, and make the warning go away. If that's not possible, let's add a secondary button that takes the user to the relevant settings page where they can change that setting.

I'll post a live comment below with a list of Warnings that need those changes.

[ockham]

Live comment to track Warning that need action buttons.

Comments Pagination:

gutenberg/packages/block-library/src/comments-pagination/edit.js

Lines 81 to 85 in c5b9ca1

	<Warning>
	{ __(
	'Comments Pagination block: paging comments is disabled in the Discussion Settings'
	) }
	</Warning>

Post Comments Form:

gutenberg/packages/block-library/src/post-comments-form/edit.js

Lines 62 to 68 in 2d62d1c

	warning = sprintf(
	/* translators: 1: Post type (i.e. "post", "page") */
	__(
	'Post Comments Form block: Comments on this %s are not allowed.'
	),
	postType
	);

gutenberg/packages/block-library/src/post-comments-form/edit.js

Lines 71 to 77 in 2d62d1c

	warning = sprintf(
	/* translators: 1: Post type (i.e. "post", "page") */
	__(
	'Post Comments Form block: Comments for this post type (%s) are not enabled.'
	),
	postType
	);

gutenberg/packages/block-library/src/post-comments-form/edit.js

Lines 80 to 82 in 2d62d1c

	warning = __(
	'Post Comments Form block: Comments are not enabled.'
	);

Post Comments:
(Note that this block shares warnings with Post Comments Form. We might want to try de-duplicating the relevant code.)

gutenberg/packages/block-library/src/post-comments/edit.js

Lines 62 to 68 in 2d62d1c

	warning = sprintf(
	/* translators: 1: Post type (i.e. "post", "page") */
	__(
	'Post Comments block: Comments to this %s are not allowed.'
	),
	postType
	);

gutenberg/packages/block-library/src/post-comments/edit.js

Lines 71 to 77 in 2d62d1c

	warning = sprintf(
	/* translators: 1: Post type (i.e. "post", "page") */
	__(
	'Post Comments block: Comments for this post type (%s) are not enabled.'
	),
	postType
	);

gutenberg/packages/block-library/src/post-comments/edit.js

Line 80 in 2d62d1c

warning = __( 'Post Comments block: Comments are not enabled.' );

[ockham]

Note that we might avoid most of these changes if we decide to implement this proposal: #40617 (comment)