#5901: Use text nodes content directly instead of stringifying using data processor in code-block

[tomalec]

as suggested by @oleq at #5901 (comment).
Ignore HTML elements inside <pre><code>.
Closes: #5901.

Suggested merge commit message (convention)

Fix (code-block): Stop rendering   when restoring the state of an empty code block. Closes #5901.

---

Additional information

There is still an issue with dom to view conversion
https://github.com/ckeditor/ckeditor5/compare/i/5901-code-blocks?expand=1#diff-82a5336a00edfc515fb87b52fc38eafbR892-R901
as you can see, filler element is not cleared on getData

From what I have found, domConverter https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-engine/src/view/domconverter.js#L1027 uses getDataWithoutFiller which strips only INLINE_FILLER. I tried to change _processDataFromDomText to strip the block filler. However, it does not identify   inside <code> as block filler, because <code> is an inline element.

I could do more changes, to let it change it anyway, given it already checked it's inside <pre> element which accepts only Phrasing content. But I have a doubt regarding that:

From what I understand domConverter is not aware of code-block feature. Therefore, for it <code> is as inline as any other element like <strong>, even inside <pre>. Shouldn't we use \u200b (zero-width space) in the first place? The pre-formatted behavior of <pre> guarantees the height for us?

//cc @Reinmar

[oleq]

The problem comes down to   being rendered in the code element in editing when the data with   is set:

editor.setData( '<pre><code>&nbsp;</code></pre>' );

and the raw editing view looks as follows (and you can move the caret before/after the nbsp):

<pre data-language="Plain text" spellcheck="false"><code class="language-plaintext">&nbsp;</code></pre>

but we'd rather expect the same behavior as with the paragraph:

editor.setData( '<p>&nbsp;</p>' );

when the raw editing view is:

<p><br data-cke-filler="true"></p>

Honestly... after a F2F call with @tomalec I came to the conclusion that we should follow through because from the end-user standpoint the original issue is serious and we can discuss this extra space quirk in a follow-up. IMO it's not a big deal and it could end up in a bigger refactoring around the DomCoverter class.

[tomalec]

Follow-up issue created #7259