[Bug]: Calendar invitation does not work when the default calendar URI is encoded

Bug description

Calendar invitation does not work when the default calendar URI is encoded.

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\NotFound</s:exception>
  <s:message>Node with name 'pers%c3%b6nlich' could not be found</s:message>
</d:error>

Steps to reproduce

1. Login as admin
2. Create new user account bob (don't login yet)
3. Run occ dav:create-calendar bob persönlich
4. Login as bob (to finish the setup)
5. Login as admin
6. Create event and invite bob
7. 💥

Expected behavior

The calendar invitation should be delivered 😎

Additional info

• Our createCalendar does not encode the calendar uri, and it's therefore possible to create calendars with umlauts. However, the calendar app does sanitize such requests. The backend itself allows it.

• If you invite someone, we look up the default calendar. That's usually the first calendar for your account. The code to handle such a propfind for schedule-default-calendar-URL is: https://github.com/nextcloud/server/blob/474720ff1c7fb996b0537a6d786e0fb930c786b0/apps/dav/lib/CalDAV/Schedule/Plugin.php#L73
  The LocalHref constructor automatically encodes the given hrefs. That is fine for all incoming requests going through the sabre http layer because Sabre\DAV\Server.calculateUri will automatically decode it again.

• Finding the default calendar is done in sabre's scheduleLocalDelivery: https://github.com/nextcloud/3rdparty/blob/ed6ea207de9e7649d5f7321497a27f5612d6e100/sabre/dav/lib/CalDAV/Schedule/Plugin.php#L432-L464. We do an internal propfind and recieve the encoded LocalHref objects in return. We pass the encoded calendar uri (e.g. "pers%c3%b6nlich") to getNodeForPath, however our backended expects that the uri is already decoded.

Possible solutions:

• Return Href instead LocalHref: Should work, but all other handlers also return LocalHref and therefore that quirks.
• Let our caldavbackend decode the uris. Not a good solution either because typically the data is decoded. I believe this opens the door for weird bugs.
• Fix it upstream in scheduleLocalDelivery.
• Don't allow umlauts. Unclear if there is a way to tell a caldav client that we do not accept the given uri.