feat(cardav): support result truncation for addressbook federation

[hamza221]

• Resolves: #

Summary

This Pr enables truncation for addressbook sync between federated instances

How to Test

• setup federation between 2 instances with this Pr checked out
• set a limit (n) or with the one I set for debugging https://github.com/nextcloud/server/pull/50092/files#diff-1800f7113f2d7ed38be65d34b8c06b99eec557811e6d7e83be1ce7fe152a7a15R859
• then either set a man in the middle to check the sync requests
• or after a succesfull sync check nextcloud logs

what to look for:

• if you're checking the request make sure that it respects the RFC Structure for truncated sync https://www.rfc-editor.org/rfc/rfc6578#section-3.6
• Check the sync token in every iteration it should be 'init_currentToken_latestTokenAtTheStartOfSync''
• at the end of initial sync it should be 'latestTokenAtTheStartOfSync'
• Make sure that all the cards are synced at the end of the sync

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[ChristophWurst]

How to test this? Does this also work with clients or is it limited strictly to server-to-server synchronization?

[hamza221]

How to test this?

The limit is set to 1 here. The ways to test this that I can think of

• Intercept the requests and check the sync token changes ,+ results (make sure that all the cards are synched, with the correct number of steps and that the sync token always reflects the correct state)
• Logs or breakpoints can also be used

PS: In case of federation both instances need to be patched.

Does this also work with clients or is it limited strictly to server-to-server synchronisation?

It should work for client sync too, But testing server to server is also needed to cover the whole PR

[AndyScherzinger]

/backport to stable31

[ChristophWurst]

Failing CI needs to be addressed and won't be resolved with rebases

[hamza221]

Does it still run into OOM with the now lower limit?

I have 224 contacts, setting it to 50 caused the OOM, I'm assuming memory is not being freed, I'm still looking into it.

Edit: Idk if it was obvious from my comment 😅 but setting it to > 224 solved the OOM exception

[kesselb]

Hi,

I did some more testing today and encountered a few minor issues. I'm not entirely sure if this is moving in the right direction, so I've pushed the changes to a different branch based on this one: #53551

1. I believe the new logic returns the wrong sync token if a non-initial sync request was not truncated: 5ca43d6.

2. We were paging through a truncated result only for initial syncs, not for regular syncs. Therefore, I added some code to expose the truncated state to the caller. This also fixes a small bug where we were triggering a deleteCard request for a card with the URI set to "system" (no such card exists, so nothing would be deleted). The reason was that the truncated state is signaled through a new response in the multistatus response, and our code was treating this new response as a vCard.

Please note that there have been some changes to config.sample.php in the meantime. If time allows, please rebase and resolve the conflicts.

[st3iny]

Tested and works with 5247 users in total and the limit configured to 2500, as Daniel suggested.