Refactor InserterMenu & VisualEditorInserter; allow recent/frequent reusable blocks to be inserted

[noisysocks]

🕺 What

Currently, InserterMenu, VisualEditorInserter, and blocksAutocompleter all directly call getBlockTypes() and getReusableBlocks() to determine what blocks should be shown as something that can be inserted.

This means that we duplicate some logic in three different places:

1. Checking, if the block has useOnce set, whether it's been already used or not
2. Checking whether or not the block has isPrivate set
3. Checking whether or not the block is in the editor config's list of enabled block types
4. Mixing in the list of available Reusable Blocks with the list of available static blocks

This approach is pretty error-prone: it's very easy to change the behaviour of one inserter and forget about the other three inserters.

To start addressing this, I've changed InserterMenu and VisualEditorInserter to source their blocks from three new selectors:

• getInserterItems - returns all items that are insertable, filters out private and disabled blocks, correctly sets isDisabled
• getRecentInserterItems - returns recently inserted items (e.g. for use in the Recent tab), filters out private and disabled blocks, correctly sets isDisabled
• getFrequentInserterItems - returns frequently inserted items (e.g. for use in VisualEditorInserter), filters out private and disabled blocks, correctly sets isDisabled

All three selectors select from both dynamic (reusable) blocks and static blocks. That means that we fix #3793 and fix #4221.

Having one place to assemble how a reusable block appears in an inserter lets us also easily fix #4303.

📅 Future work

The next step is to make blocksAutocompleter pull from getInserterItems. I've not done this yet as doing so would rely on being able to access editor state from the blocks module—something that we haven't figured out yet.

✅ How to test

1. Insert some static blocks and reusable blocks
2. Recently inserted blocks should move to the top of the Recent tab in the main inserter
3. Frequently inserted blocks should appear at the bottom of the visual editor
   1. Double check that a block can be inserted by clicking one of these items
4. Recent and frequent blocks should persist if you create a new post

[aduth]

Thoughts on this approach, @youknowriad and @aduth?

If insertable blocks are largely state-derived, I agree it's sensible that they could be implemented as selectors.

One potential issue I see with the current implementation is with memoization via createSelector. Since we're only busting the cache on changes to state, but not on newly-registered block types, we might run into issues where blocks don't appear correctly. This could be accounted for by returning getBlockTypes() as part of the second argument of createSelector.

[noisysocks]

Note from #4139 (review): We should remove the reusable block from recentInserts and insertsFrequency when a reusable block is deleted.

[noisysocks]

✨ This is ready to be properly reviewed now.

[noisysocks]

This could be accounted for by returning getBlockTypes() as part of the second argument of createSelector.

I looked into this and createSelector relies on one passing immutable objects as the second argument. This means that passing in getBlockTypes() would cause the selector to always be invalidated.

My gut says that it's OK to leave this as is since registering a block type is unlikely to happen after the editor is instantiated—no?

[noisysocks]

Going to split this work into smaller PRs that are less intimidating to review.

[aduth]

Going to split this work into smaller PRs that are less intimidating to review.

See #4497