RFC: carddav: make principal path a DAV:collection

[bitfehler]

While not strictly necessary for a pure CardDAV client, this change
allows a plain DAV client to start from the principal path and discover
the home set and within it the addressbook objects.

Example cadaver session:

conrad@serotonin ~/go/src/github.com/emersion/go-webdav $ cadaver http://localhost:8080/Y29ucmFk/
Authentication required for Please provide your IMAP credentials on server `localhost':
Username: conrad
Password:
dav:/Y29ucmFk/> ls
Listing collection `/Y29ucmFk/': succeeded.
Coll:   contacts                               0  Jan  1  1970
dav:/Y29ucmFk/> cd contacts
dav:/Y29ucmFk/contacts/> ls
Listing collection `/Y29ucmFk/contacts/': succeeded.
        1ddb4906edda8d7b63caf30414f3f9491c065b46.vcf        225  May  3 16:15
        8440297a76458ead82593d7bb85eb26861a31c27.vcf        212  May  3 16:22
        cfbaf6f7a40a58cc9dd54c6a112d9c4edd3c96e3.vcf        216  May  3 16:16
dav:/Y29ucmFk/contacts/>

This did not work before.

While most clients work fine without this, I understand this to be a requirement for this setup to be valid WebDAV (highlighting mine):

For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.

Note: This PR is actually mostly to highlight an issue I noticed. Both with and without this change, the code was actually no longer compatible with the old "both user principal URL and home set URL are /" approach (I broke it, sorry), because if the two are equal the properties for the latter will never be returned.

I initially looked into supporting that, but doing so really complicates things. Imagine this change while keeping that approach working. The code would have to handle:

• Path is principal URL -> add principal properties
• Path is also home set URL because they are equal -> add home set properties to same response
• Path is principal URL, not home set URL, depth is > 0 -> add home set properties as new response
• Path is principal URL and home set URL, depth is >0 -> add address objects as new responses
• Path is principal URL, not home set URL, depth is >1 -> add address objects as new responses

This would however make the assumption that the home set URL is actually under the principal URL, which I suppose doesn't even have to be the case.

So what to do? I think the questions are:

• Do we care about this being plain WebDAV compatible? We could say we don't, and if an implementation needs that, it should handle requests to anything below the home-set path itself?
• Do we want the "multiple things at the same path" approach to keep working? If so, I think it would require some refactoring of the propfind*() functions so they can add properties to the same response.

Also, maybe you have some other thoughts or ideas? 🙂

[bitfehler]

Closing this, it is superseded by #99