[LDAP] improve processing nested groups

[blizzz]

• split walkNestedGroups into two distinct methods, for $recordMode determiniation was always wrong in subsequent runs. This also simplifies the code.
• add runtime caching to avoid duplicated LDAP requests. Later on, members are cached on Redis.

[blizzz]

@CarlSchwan @come-nc there is something nagging me about the memory cache:

server/apps/user_ldap/lib/Group_LDAP.php

Lines 78 to 80 in 04bafe7

	$this->cachedGroupMembers = new CappedMemoryCache();
	$this->cachedGroupsByMember = new CappedMemoryCache();
	$this->cachedNestedGroups = new CappedMemoryCache();

This defaults to 512 stored values and is an arbitrary value in this context. My first urge was to remove the CappedMemoryCache and turn it in a simply array. But I am afraid it would potentially cause memory exhaustion errors. I like to keep the safeguard here.

Then I thought about increasing the size, although with calculated maximum values it would seem safer to decrease the capacity of the latter two caches! Since there are no known issues I am aware of, the assumption is rather conservative.

For each entry of the first cache I am calculating with 64 bytes for the key (group ids), and the value being an array with 20 times up to 255 characters/bytes (DNs). I do not consider the array overhead. It is about 0,3 MB per entry. Accepting to take 256MB in total, it would allow for 822 entries.

The second is "misused" by the PR to store more infomration (i.e. could split), and it would store also DNs as key and lists of DNs as values. Each entry might turn about 1.3MB allowing 206 entries. Same for the last cache.

Please check whether my math is wrong :D

But given it is not, I am a bit unsure how to move on.

Evaluation the assumptions may be one. The max values are already not production ones (but the number of groups is an assumed average). With the assumption of the DN being 100 chars on average, 1342 entries could be kept already. And assuming the gid is also rather a third, the first cache could hold more than 6000 entries.

Calculations could be applied (perhaps running once weekly or via occ):

1. Allow half of the available RAM
2. Calculate average gid + DN length
3. Calculate average number of group memberships
4. => with this calculate the entries save them in appconfig.
   And keep the default of 512 for stability?

And I think nevertheless the newly used cache should be split (especially both uses cases come into question here), as well as the third cache 😒 I shall revise them, after about 7 years.

[blizzz]

superseded by #30223 and #33703