[PB-4662]: fix/nautilus-webdav-client-bug

[AlexisMora]

In this pr there is two main fixes in order to fix the navigation with nautilus file explorer:

No trailing Slash While PROPFIND request:

Debugging I found that the nautilus file explorer does not attach a trailing slash while performing PROPFIND requests. In order to fix this I needed the change the way we diferenciated a file from a folder and move the check from the parsing (on getRequestedResource) To the getDriveItemFromResource method.

Essentially, what I changed is that since we cannot guarantee that a requested item is either a folder or a file because of the trailing slash, now we directly fetch for folder if a trailing slash comes on the request, otherwise we "optimistically" assume that it is a file and we fetch for it, if we cant find a file item, then we will fetch for the folder instead.

Change in the PROPFIND response from 207 multistatus to 404:

While navigating and testing in nautilus file explorer i found out an error that got the file explorer stuck in an infinite loop, and that was mainly because we where sending a 207 multistatus response and this led to think the nautilus file explorer that the destination folder already had a file with that name.
Quoting RFC 4918

If there is an error retrieving a property, then a proper error
result MUST be included in the response. A request to retrieve the
value of a property that does not exist is an error and MUST be noted
with a 'response' XML element that contains a 404 (Not Found) status
value.

Consequently, the 'multistatus' XML element for a collection resource
MUST include a 'response' XML element for each member URL of the
collection, to whatever depth was requested.

it is safe to assume that we should always return a 207 with the necessary response then, but this led to an infinite loop.
Also, on another paragraph:

9.1.2. Status Codes for Use in 'propstat' Element

In PROPFIND responses, information about individual properties is
returned inside 'propstat' elements (see Section 14.22), each
containing an individual 'status' element containing information
about the properties appearing in it. The list below summarizes the
most common status codes used inside 'propstat'; however, clients
should be prepared to handle other 2/3/4/5xx series status codes as
well.

So this lead me tho think that while it is true about the 207 multistatus response with each individual property of a resource, if there is no resource to retrieve, then we should send a 404 and we are still rfc compliant because of this sentence:

clients should be prepared to handle other 2/3/4/5xx series status codes as well.

Clients tested

I have succesfully tested with:

• Nautilus explorer
• Cadaver
• rclone
  and all operations seems to work as intended. I even did a 500mb Sync operation with multiple nested folders and files and seems to be working as usual, with a total upload time of the version 1.5.8 of ~21 Minutes and with the introduced changes of ~22 Minutes, both with an average of 400 KiB/s

[sonarqubecloud]

Quality Gate failed

Failed conditions
65.5% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud