Collection list refresh: Don't update fetched homesets

[sunkup]

Purpose

At collection list refresh DAVx5 updates homesets when detected a second time. This leads to homesets detected as personal at first encounter (directly within the user principal), wrongly being overwritten as non-personal homesets (when found in a group principal afterwards).

This PR alters CollectionListRefresher.discCoverHomesets() to remember homesets already saved to database during the same refresh and won't overwrite/update them. They might only be updated at a second refresh if changed on server.

Short description

• add a set of http urls alreadyFetched property to CollectionListRefresher
• before saving/updating a homeset check wether it is in the set / has already been fetched
• after saving/updating a homeset, add it to the alreadyFetched set
• test the new behaviour

Checklist

• The PR has a proper title, description and label.
• I have self-reviewed the PR.
• I have added documentation to complex functions and functions that can be used by other modules.
• I have added reasonable tests or consciously decided to not add tests.

[rfc2822]

I'm still not sure that I understand the difference between "queried" and "saved". However maybe this example illustrates it:

• We query a principal and find N homesets. So we mark one URL (the principal) as "queried", but all the N homesets as "saved".
• We query another related URL and find again M homesets. So we mark the related URL as "queried", but all the M homesets as "saved". The homesets from the step before won't be added again, because they're already "saved". So "saved" applies to the operation of saving, while query makes sure that we don't query twice. Which are different things.

Is that correct?

But shouldn't the "saved" then apply to everything we find/save? There are other calls to homeSetRepository.insertOrUpdateByUrl() which are not checked against "alreadySaved". I wonder if we even should add/check the collections to "alreadySaved", too?

I understand that the change fixes our current issue. But I wonder if one would still understand the code / what it does without knowing about the current issue. However this should be the aim.

---

Another thing: we get the service and thus servcice.type as argument. Can we take the

val homeSetClass: Class<out HrefListProperty>
val properties: Array<Property.Name>
when (service.type) {
    Service.TYPE_CARDDAV -> {
        homeSetClass = AddressbookHomeSet::class.java
// …

block out of the discoverHomesets and make it properties of the object? It's not need to evaluate it more than once and I think it makes the discoverHomesets even more difficult to understand.

[sunkup]

Is that correct?

That's exactly right. I renamed alreadyFetched to alreadySaved to make it more clear. alreadySaved should hold the URLs of home sets which have been saved to the database already. alreadyQueried should hold the URLs of principals wich we have made propfinds on and don't want to send a propfind to (query) again.

But shouldn't the "saved" then apply to everything we find/save? There are other calls to homeSetRepository.insertOrUpdateByUrl() which are not checked against "alreadySaved". I wonder if we even should add/check the collections to "alreadySaved", too?

I don't think so. I think by that argument already"Queried" would then have to apply to (remember) everything we query too - which we don't, since it does not really make sense to do that.

I can see however that both alreadyQueried and alreadySaved are only used in discoverHomesets() - so do not necessarily need to be properties accessible by other methods in CollectionListRefresher. I think alreadyQueried was made a property because discoverHomesets() is recursive, but we could simply add them both as parameters to the function. That makes their usage clearer and the class less confusing.

Furthermore I will rename alreadySaved to alreadySavedHomeSets, since it will only store home sets and alreadyQueried should only contain URLs of queried principals so that will be alreadyQueriedPrincipals. This should make it clear that other queries and "saves" are not held by these sets of URLs.

See the changes in 1f45c60

---

Can we take the [...] block out of the discoverHomesets and make it properties of the object?

I guess we could, but by aforemented reasoning I would leave it in the discoverHomesets method. Semantically it belongs there and that is also the only method where it's used. Or what we could do is to create another discoverHomesets method which takes care of the "setup" and then starts the actual recursion.

See the changes in 7247691