Reduce number of database queries during WebDAV propfind request

[starypatyk]

While working on nextcloud/android#10783 I have found the following.

• When reading complete data for a folder the Android client requests the nc:note attribute in the WebDAV propfind request.
• Current implementation of retrieval of this attribute executes four separate database queries for each file in the folder.

With help of @PVince81 I have been able to refactor the code to avoid issuing additional database queries, since required data is already loaded into memory.

Performance is improved significantly - almost four times faster in my tests (331 files in a folder)

_	Execution time [ms]	# of DB queries
Before	1300	1699
After	350	372

Proposed changes introduce a slight change in behaviour when a file has been shared more than once with the same user - e.g. with a direct share and a group share.

• Previously in this case only note from the first share found was returned.
• Now notes from all shares are concatenated (with a new-line) and returned.

With the new implementation the notes are presented like this in the Android client:

I have not been able to find the share notes in the UI of the web client.

[starypatyk]

I have looked at the failing tests.

Apparently the performance-8.0 test is not prepared for PRs from cloned repositories.

Run git fetch origin dav_read_share_notes
fatal: couldn't find remote ref dav_read_share_notes
Error: Process completed with exit code 128.

Regarding acceptance tests - the errors are suspiciously close to my changes (both relate to the sharing feature). Unfortunately I have not been able to correlate the reported errors with potential errors in the backend. Are logs from the backend available somewhere for the failed run?

[PVince81]

@starypatyk the acceptance test issues are not related to your code changes. These are tests that randomly fail on CI (but not locally) which we were not able to fix yet.

[PVince81]

👍 see minor comment

[PVince81]

/backport to stable25

[PVince81]

I've restarted the CI jobs that timed out.

Then this should be good to merge

[starypatyk]

I am not sure about next steps. The tests are successful - except performance tests (irony 😉) that seem not to be prepared when PR comes from a fork.

Should I merge it myself? I am not even sure that I have required permissions...
Or should I wait for merge by someone from the server team?

I have no problem with the delay, but I would not like to block things.

[PVince81]

@starypatyk thanks a lot for your contribution!

we'll take it from there, it will get backported to stable25 and after 25.0.0 is out we can merge the backport for 25.0.1