Block Editor Stats - Generalize block variation tracking.

[Addison-Stavlo]

Changes proposed in this Pull Request

• Applies a generalized solution for tracking block variations in block tracking events.
• Instead of implementing variation tracking on an ad-hoc basis, we can update this to use getActiveBlockVariation from the core blocks store. This will ensure our variation tracking is up to date with any changes to attribute schema, variation isActive functions, and as new blocks with variations are added to the library.
• This means that variation_slug will appear as a property for all block types, and will be populated as undefined if no variation is active.

Testing instructions

• Follow steps to enable tracking debugging at PCYsg-nrf-p2
• Insert an embed block variation and verify that variation_slug of the tracking event is populated with the same value as before.
• Insert a social icons block, from there insert a social-link block variation and verify variation_slug is populated with the same value as before.
• For blocks without variations, such as paragraph, verify variation_slug is undefined.
• With FSE active, insert a "Header" block (variation of template part) and verify variation_slug is "header".

Related to #
#53410

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[david-szabo97]

Awesome! This is a lot better!

Tests well for me! 🚢

[retrofox]

It's nice to see the API exposes a way to get the block variation properly. Thanks this improvement.

[kraftbj]

Note when this was released to wpcom-block-editor on wp.com, it had to be reverted due to error that getActiveBlockVariation was not a function. See p1623442537376200-slack-C010KDAPG49

[fullofcaffeine]

Is that something that depends on a specific Gutenberg version being available, perhaps?

[david-szabo97]

Yes, that's a relatively new feature in Gutenberg. Opening a PR to fix this.