onWriting Flow: Remove the provisional block behavior

[youknowriad]

closes #8678

I admit I never been fan of the provisional block behavior: The fact to remove an empty paragraph right upon its creation if it's unselected though I understood it was useful when it was too easy to create in between paragraphs which is not the case anymore.

I think it's better to remove it to avoid any unwanted side effect it can create like #8678. Thoughts @jasmussen @aduth

Testing instructions

Repeat instructions in #8678 and check that it works properly.

[youknowriad]

I hesitated to keep this selector fo BC but the probability for it to be used outside Gutenberg is 0 IMO

[aduth]

Alternatively, we could keep the function, and have it return null (the default reducer state) so it would at least not throw an error and be as close as possible to a real value with the state no longer existing.

But I'd probably agree it's unlikely that this is used.

[youknowriad]

I want my badge @tofumatt 😄

[aduth]

Thoughts ahead of my review: I agree this has added complexity and therefore caused fragility. It's interesting to consider this as the cause for #8678.

Usage-wise, I'm trying to remember back to #5417 / #5396 and the issues this was meant to address:

• The inserter line was certainly easier to hit at the time (it spanned the full content width and was quite large).
• I guess we don't show the sibling inserter if there's already a blank new paragraph between two other blocks? I recall one of the issues being that you could easily add many empty paragraphs and the placeholders would be visually ugly.
• In retrospect, the auto-deletion seems quite extreme, though it is a bit strange to see the writing placeholder "Add text or type / to add content" when clicking sibling inserter and then to another block; perhaps the best avenue here is to limit the effect of the placeholder. Or maybe it's completely fine as it is.

[aduth]

There's still one instance of the phrase "provisional" in the codebase in writing-flow.test.js. Unsure if we want to abandon the terminology altogether. In the test, I believe it's more accurately referring to an unmodified default block.

gutenberg/test/e2e/specs/writing-flow.test.js

Lines 151 to 153 in ee6060f

	// When returning to Visual mode, backspace in selected block should
	// reset to the provisional block.
	await page.keyboard.press( 'Backspace' );

[aduth]

Alternatively, we could keep the function, and have it return null (the default reducer state) so it would at least not throw an error and be as close as possible to a real value with the state no longer existing.

But I'd probably agree it's unlikely that this is used.