New link editor followup

[mhsdesign]

The new link editor was introduced via #3996 and finalised via #4037 - now we still found a few bits and pieces that have to be finial final finalised:

2. During search the tree also searches through content and shows all these contents ... that makes the search already slower and yields a lot of output which is of no use as one cannot link to a main content collection or its children

3. Bottom to top approach for search and for selected node id possibly in-performant as we go upside to find the ancestors and for each level we find the siblings. -> The resulting order is thus also possibly wrong! See test.

Maybe findSubtree needs a nodeId instead of depth to look that deep? And also a search term filter?

4. Use findSubtree instead of multiple findChildren queries to build up initial tree

5. Use new json dimension space point in client instead of legacy 8 format

6. Starting points as node paths are effectively obsolete with nodes carrying no names regularly, promote to use node ids but find a pattern that developers define node ids for project? -> HIghlander nodes.

7. Write documentation how to write new link type as plugin (figure out how the Web tab is by default asked at last with isSuiteable as it matches all always?

8. Some projects require to use the FlatNav package and hide nodes from the tree which appear a lot like blog posts or news entries. If the base node type filter excludes them and they are better displayed in another view like FlatNav the link editor should also show them separate:

• this probably requires that FlatNav or the like get supported in the core or that FlatNav ships a link editor plugin
• if this results in two tabs, e.g. two link types the node:// protocol has no clear tab where editing could start, but that information must be available for the link editor during opening without requires.
  • either we extend the node protocol like node://news/ or we see that the FlatNav will be part of the current link editor tab and one can switch inside that tab between the document tree and a flat nav

9. extract NodeTree building into Shared namespace so the upcoming WIP: FEATURE: New reference editor (DD Sprint) #4021 can us it.

There are some utterly verbose and heavy CR core things like node type multiplication which must definitely reside in the CR core. We should attempt to make the tree builder more lightweight and use rather CR core things than that the Neos Ui introduces duplicated code.