Fix lookup server connector background jobs problem

[nickvergessen]

Some 50 user instances have 400k pending jobs for lookup updates
The first problem is that the job was scheduled too often with #15020
The second one is that each time any value changed, a new job was scheduled (because at least the retry count and the last execution was different).
So you ended up with 6 jobs per change on user data.

As LDAP seems to set the user name/email some more times, it basically added the 6 jobs on each login?

So now the app got a little update and in the end can only have 1 background job per user.
Existing update requests are killed when the userId is not set in the arguments, so the table should clean up on the next few cron runs after the update.

[blizzz]

As LDAP seems to set the user name/email some more times, it basically added the 6 jobs on each login?

Hooks should not be fired if there was no change. But then, if every change lead to a new background job being created (and with the double-triggering you fixed on in another PR) 3 changes might be possible. Email, Displayname for sure, then perhaps avatar and/or quota.

[rullzer]

Didn't test in dept but makes sense

[kesselb]

Could you rebase? 🤔

[rullzer]

@kesselb rebase happend. review?

[nickvergessen]

Still waiting for reviews @MorrisJobke @blizzz @ChristophWurst

[MorrisJobke]

Tested and works 👍

[MorrisJobke]

Let me rebase to trigger CI again.

[MorrisJobke]

@nickvergessen Should we back port this?

[nickvergessen]

In theory it would be cool, but I think its too heavy :/

[MorrisJobke]

In theory it would be cool, but I think its too heavy :/

Okay. Then keeping it here.