Block options: disable mode toggle when block is in warning state

[johngodley]

Description

If you put a block into a warning state the block option 'Edit visually' and 'Edit as HTML' are still available and toggle state, but have no outward effect on the block.

To avoid user confusion this PR disables the mode toggle option when a block is showing a warning. As soon as the warning is cleared the option is restored.

Fixes #7743

How has this been tested?

Additional unit tests have been added to test the mode toggle enable/disable.

Manually test that the 'edit visually' and 'edit as HTML' options are removed from the block 'more options' menu:

• Add a paragraph block, edit as HTML, and remove the trailing </p> to trigger an invalid block warning
• Access the block 'more options' menu and verify that the 'edit visually' and 'edit as HTML' options are removed (see above screenshot)
• From a developer console type wp.blocks.registerBlockType( 'myplugin/mr-crashy', { title: 'Mr. Crashy', category: 'common', icon: 'warning', edit() { throw new Error(); }, save() { return ''; } } );
• Add Mr Crashy block to a post
• Verify that the crashed block 'more options' also does not show 'edit visually' and 'edit as HTML'

Types of changes

This PR changes the behaviour of an existing feature.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[ZebulanStanphill]

Would it make more sense to still show the options, but have them be disabled?

[aduth]

Note this just adds the capability for additional actions, but doesn’t actually include any

YAGNI.

[aduth]

Aside: This pull request includes a few too many unrelated changes that's made it more difficult than it should be to review in tandem.

[aduth]

Are we increasing the z-index for the block warning specifically, and if so, will it have negative consequences on any other "EditorWarnings" present in the application? It was meant to be made separate for general reusability, and thus we should be aware of cascading effects on other usage. Alternatively, we could create a separate z-index for the specific block warning.

[aduth]

Why was this moved?

[johngodley]

@aduth this PR is a work in progress and contains the contents of other PRs, specifically #7866 which is handling the changes you commented on. Once the other work is finished I'll remove it from this one so it just contains the relevant code.

@SuperGeniusZeb possibly, I'll need to consult with a designer

[johngodley]

Rebased all the cruft out and went with the suggestion from @SuperGeniusZeb to disable the item, as shown in the updated screenshot. It should be good to go now.

There's a Travis CI e2e failure which seems unrelated to this PR

[johngodley]

Closing in favour of #9088