webdav backend requests unnecessary properties for file listing

When the the webdav backend tries to download a file listing of a directory, it sends no HTTP body in the request.
This is equivalent to requesting essentially all properties of the files in the listing. (Actually, the code has been changed here. Before the change, duplicity request all properties explicitly using "allprop". See line 117 in webdavbackend.py for a pointer to the relevant paragraph in the RFC.)

This leads to unnecessary large responses from the server that I use (sd2dav.1und1.de). The response is so large that it is even truncated after about 1.2 MB. Consequently, duplicity is not able to parse the XML in the response. I don't know if the truncating happens at client side or at server side, and I don't have the time to debug that right now.

The response can be shortended drastically by only requesting minimal information. The only information that is necessary and used by duplicity is the filename.

The attached patch solves my problem caused by truncating the reply and improves the performance of the webdav backend. It should be standards compliant but of course I don't know if it causes again problems with weird servers.

At the moment, my server sends that much per file:
<D:response xmlns:ns2="http://apache.org/dav/props/" xmlns:ns666="urn:schemas-microsoft-com:" xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/">
<D:href>***FILENAME REDACTED***</D:href>
<D:propstat>
<D:prop>
<ns2:executable>T</ns2:executable>
<ns666:Win32CreationTime>Sun, 28 Sep 2014 22:12:06 GMT</ns666:Win32CreationTime>
<ns666:Win32LastModifiedTime>Sun, 28 Sep 2014 22:12:06 GMT</ns666:Win32LastModifiedTime>
<ns666:Win32LastAccessTime>Sun, 28 Sep 2014 22:12:06 GMT</ns666:Win32LastAccessTime>
<ns666:Win32FileAttributes>0</ns666:Win32FileAttributes>
<D:getetag>03.1091326433.201</D:getetag>
<D:creationdate>2014-09-28T22:12:06Z</D:creationdate>
<D:getlastmodified>Sun, 28 Sep 2014 22:12:06 GMT</D:getlastmodified>
<D:displayname></D:displayname>
<D:resourcetype></D:resourcetype>
<D:getcontentlength>26188443</D:getcontentlength>
<D:getcontenttype>application/octetstream</D:getcontenttype>
<D:getcontentlanguage></D:getcontentlanguage>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
<D:lockdiscovery/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>

After applying the patch, it looks like that (I don't know if it's really minimal):
<D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/">
<D:href>***FILENAME REDACTED***</D:href>
<D:propstat>
<D:prop>
<D:resourcetype></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>