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.