NewPropFindResponse uses callbacks to lazily build the response.
However, some props are static: they don't require any processing
to generate. Add a small helper to reduce boilerplate a bit.
This CL corrects the following bug uncovered by staticcheck:
```
internal/elements.go:148:6: this comparison is always true (SA4023)
internal/elements.go:146:18: the lhs of the comparison gets its value from here and has a concrete type
```
Signed-off-by: Sebastien Binet <binet@cern.ch>
One common method for CalDAV or CardDAV clients to find the current user
principal URL is to request the `/.well-known` URL (see [RFC 6764,
section 6][1]), expecting a redirect. Such URL is for example a valid
result of the discovery phase described in that RFC. The expectation is
that a client, given such URL, is able to find the principal URL by
following a redirect when sending a PROPFIND request.
This change makes `PropfindFlat()` (and, by extension,
`FindCurrentUserPrincipal()`) handle such a redirect and correctly
return the requested properties, even if their HREF is different from
the original request path.
[1]: https://datatracker.ietf.org/doc/html/rfc6764#section-6
Backends will need some way to signal that a precondition error occurred
(and specifying which one) without causing the server to return a 500.
This commit adds an exported function to create a specific error for
this. The existing error handling routine is slightly adapted to handle
this error in such a way that it returns the desired result.
Usage would be something like:
```
return "", carddav.NewPreconditionError(carddav.PreconditionNoUIDConflict)
```
which triggers the following HTTP response:
```
HTTP/1.1 409 Conflict.
Content-Type: text/xml; charset=utf-8.
Date: Thu, 10 Mar 2022 10:28:56 GMT.
Content-Length: 141.
Connection: close.
<?xml version="1.0" encoding="UTF-8"?>
<error xmlns="DAV:"><no-uid-conflict
xmlns="urn:ietf:params:xml:ns:carddav"></no-uid-conflict></error>
```
This response gets correctly recognized by e.g. Evolution (though it's
handling is not great).
The added error type is generic enough to be used for other stuff also.
As it is not exported (internal package), new functions for creating
such errors would have to be added.
