Breadcrumbs don't resolve conflicting spaces / are only path based

[kulmann]

Followup of #7725

Breadcrumbs are currently built from parent paths segments (i.e. only path based, no fileIds present). As a result, the breadcrumbs might resolve to the wrong space if you have two or more spaces with identical drive aliases (drive alias clashes are allowed, we need fileIds to resolve the correct space).

To solve this we need a sequence of propfinds, with each propfind being on the fileId of a folder and requesting the respective parent folder id, until we reached the root of the space.

Side note: we can collect the shareTypes of all parent folders as well. This would resolve the issue that we currently request all shares via OCS. Doesn't need to be implemented in the same PR, but should be prepared.

[tbsbdr]

imo cornercase but consequences could be really ugly. I need to real-time talk with you about this to give it a proper prio.

[kulmann]

Turns out: the breadcrumbs work correct without the fileId because we already have a resolved space (from DriveResolver.vue component / useDriveResolver composable) and when the drive alias doesn't change we don't try to re-resolve the space. We only extract the updated relative item path. The fileId gets added back to the URL (because we have a mechanism in place that does that). Definitely not a GA blocker, everything works. Just could be "more precise" with the fileId already being in the route to the parent folder. No other added value.

[kulmann]

We have the ancestorMetaData available in the resource pinia store by now. That is all the information we need (a fileId for each and every parent folder up to the space root). The function which builds breadcrumb items needs to be refactored to take the fileIds into account as well. But as already stated, prio is really really low because it fixes no bug at all.