Framework: Remove deprecations slated for 3.4 removal

[pento]

This PR removes deprecations scheduled to be removed in the upcoming 3.4.0 release.

• focusOnMount prop in the Popover component has been changed from Boolean-only to an enum-style property that accepts "firstElement", "container", or false. Please convert any <Popover focusOnMount /> usage to <Popover focusOnMount="firstElement" />.
• wp.utils.keycodes utilities are removed. Please use wp.keycodes instead.
• Block id prop in edit function removed. Please use block clientId prop instead.
• property source removed. Please use equivalent text, html, or attribute source, or comment attribute instead.

Source: https://wordpress.org/gutenberg/handbook/reference/deprecated/#3-4-0

[pento]

Note: the id prop is still actually being passed to edit, as this comment says it's going to be removed in 3.5:

gutenberg/packages/editor/src/components/block-edit/edit.js

Lines 31 to 39 in 2d54b09

	// TODO: `id` prop is to be removed in 3.5 "UID" deprecation.
	return (
	<Component
	{ ...props }
	id={ props.clientId }
	className={ className }
	/>
	);
	};

[gziolo]

@jorgefilipecosta, I think I missed something here, can you help?

[jorgefilipecosta]

Hi @gziolo, this code is to keep compatibility with the old Gutenberg theme support. The code block // Backcompat for Color Palette set through "gutenberg" array. should also be removed.
I also did a checkup on the logic and we had missed a removal in a previous version so I removed that code. I added my changes in a new commit 417203c.

[gziolo]

I added a commit with a code removal for PHP part. I think I did something wrong though. @jorgefilipecosta @pento can you do sanity check?

[aduth]

Note: the id prop is still actually being passed to edit, as this comment says it's going to be removed in 3.5:

The block id prop was deprecated in a version prior to the bulk of the uid -> clientId renaming, so the comment isn't accurate (said as the person who likely authored it).

I think we should remove it now, consistent with our deprecated messaging.

[aduth]

Anecdote: I only stumbled upon this by chance. Fewer touch points with deprecations is better, ideally colocated with the deprecated function call which is the target of our linting rules.

[aduth]

E2E tests are struggling with unrelated issues, but otherwise this is looking good.

[aduth]

• Rebased to resolve conflicts.
• Removed id prop passing to edit in 81dce98
• Updated Freeform block, which apparently still depended on props.id, to use props.clientId

The last of these could do for a bit of extra testing / observing whether other blocks have similar deprecated usage.

[pento]

Changes are looking good, @aduth. No apparent problems, and I couldn't find any other blocks that appeared to be using the id prop. (An exception is GalleryImage, which is explicitly passed a prop called id.)

I ran across a fun little issue that was caused by id changing to clientId: React doesn't like when you pass a camelCase prop to a HTML element that it doesn't know what it should do with. Also reported in #8136.

[aduth]

I ran across a fun little issue that was caused by id changing to clientId: React doesn't like when you pass a camelCase prop to a HTML element that it doesn't know what it should do with. Also reported in #8136.

This sounds like it's always been a buggy implementation, if it was blindly applying the props when said props include block-specific values. It's also why ...props spread application on elements can be discouraged.