Consider letting EditorImageDialog return canonical public:// file URLs and let the drupalimage CKEditor plugin transform those to the correct URLs

Problem/Motivation

Follow-up for #2666382: EditorFileReference filter: generate URLs for inline images → , see #2666382-16: EditorFileReference filter: generate URLs for inline images → .

For detailed background information, see the issue summary of #2666382: EditorFileReference filter: generate URLs for inline images → . In that issue, we focused on the bare minimum necessary to solve the key problem: we implemented point 3 of the proposed solution:

1. Store embedded image paths as public://whatever instead of /sites/[sitename]. Or even better, don't set a path, since it is completely irrelevant when we have the entity id in there already.
   
   If <img data-entity-type="file" data-entity-uuid="foo" src="#" alt="..." title="..." /> was all I saw in the database it would make me very happy and confident I could do pretty much anything to the site as long as the managed_files table is intact.
2. Have the editor image plugin replace the private|public path with the actual path just before switching to WYSIWYG mode (and do the reverse when going to source mode).
3. Have a filter perform the same replacement before content is rendered.

This issue is about considering to implement points 1 and 2. The main reason we'd want to do that is for semantical correctness. It doesn't bring any real-world benefit, except for one: when a site that lives in a subdirectory is migrated (or deployed) to no longer live in a subdirectory or vice versa, this would ensure that the preview in text editors like CKEditor would still work.

(The content that end users see, i.e. post-filtering, already is guaranteed to always work thanks to the changes in #2666382: EditorFileReference filter: generate URLs for inline images → .)

Proposed resolution

Implement points 1 and 2. Note that it comes with some downsides: we could do points 1 and 2, but:

1. then we have automatic-processing functionality in CKEditor that every other text editor will also need to implement
2. then we need to make the drupalimage CKEditor plugin aware of which specific text format filters are used, and act only when appropriate
3. then we need to write JS test coverage — I try to change Drupal core's custom CKEditor plugins as little as possible
4. I do see that that is semantically more accurate, but I don't see it gaining us much in practice

Remaining tasks

Discuss.

User interface changes

None.

(Well, except that using the Source view in CKEditor would start showing file URLs like public://inline-images/llama.jpg instead of /sites/default/files/inline-images/llama.jpg.)

API changes

None.

Data model changes

None.