Gutenlypso: Register server-defined blocks attributes

[Copons]

Changes proposed in this Pull Request

• Manually register the server-defined dynamic blocks (e.g. Latest Comments) attributes.

Dynamic blocks are registered server-side, and their attribute are loaded through the unstable__bootstrapServerSideBlockDefinitions function, called server-side as well.

Gutenlypso doesn't have access to the same JS globals so it doesn't have any information about the dynamic blocks' schema and attributes.

This PR is a bit of a clumsy workaround, and proposes to manually register the attributes of server-defined blocks during the Gutenlypso initialization.

For now, I've only worked on the Latest Comments block because it's a major offender (all its attributes default to true, so fallbacking all of them to false is very visibly incorrect), and because I'd like to discuss this change before working on more blocks.
Please compare this PR with how the block defines its attributes in PHP.
Is my solution a viable, or even desirable?

Testing instructions

• Open /block-editor.
• Insert the Latest Comments block.
• Check that its preview correspond to its sidebar settings defaults:

Fixes #27963

[matticbot]

Test live: https://calypso.live/?branch=fix/27963-dynamic-blocks-attributes

[gwwar]

We'll want to work with WordPress core to make sure we can access these in a cleaner way. @Copons do you mind filing an enhancement issue in https://github.com/WordPress/gutenberg/issues ?

cc @gziolo @aduth @youknowriad

I'm thinking maybe a custom wpcom endpoint for now to fix the issue, or embedding a similar global on the app skeleton for this section.

[gziolo]

No need to create an issue, we have a huge issue which is one of the goals of Gutenberg phase 2 (WordPress/gutenberg#13113).

In fact, there are 2 issues opened:

• Block API: Server-side awareness of block types
• Expose available blocks via an API - which is more narrow and better fits to what you described

Please leave your comments there if you have some ideas.

Let me also re-share a part of my comment I left in the last issue:

We did some explorations (#5802) in the past how we could move attributes to the server and even allow to filter them, so plugins could have a better control over it. It's all doable and can still continue to work with the existing JS API.

There was also another exploration (#5652) to use JSON files to share definitions between JS and PHP which I found very promising myself. Example structur:

{
  "name": "core/categories",
  "category": "widgets",
  "supports": {
	"html": false
  },
  "attributes": {
	"showPostCounts": {
	  "type": "boolean",
	  "default": false
	},
	"displayAsDropdown": {
	  "type": "boolean",
	  "default": false
	},
	"showHierarchy": {
	  "type": "boolean",
	  "default": false
	},
	"align": {
	  "type": "string"
	}
  },
  "render_callback": "render_block_core_categories"
}

There might be other ways to solve this. What I'm sharing is what I actually coded as an excercise to see what could work.

[Copons]

Alternative approach with a custom WPCOM endpoint at #30045 + D22987-code

[Copons]

Replaced by #30045