perf: Only apply default settings when user is created or settings are requested

[provokateurin]

Before every authenticated request caused a query (SELECT * FROM "oc_notifications_settings" WHERE "user_id" = :dcValue1; {"dcValue1":"admin"}) which was largely unnecessary, stemming from the PostLoginListener.

Now the default settings are only initialized when the settings are requested and don't exist already.
To make sure the next send time is set for new users, the default settings are also initialized when a new user is created.
A tiny additional improvement is that the user values are not set now if the user doesn't change them, so if the app default is updated the user default will be updated as well (and it saves the additional queries to insert the rows into the table).

[come-nc]

Good for me code wise, I do not know about the behavior change regarding defaults, waiting for @nickvergessen comment.

[nickvergessen]

Will check later this week or first week of June

[nickvergessen]

Rebased on master to have a fresh footprint

[nickvergessen]

The integration test query count is a bit rigged as all requests don't use cookies and therefore authenticate again everytime. So I checked PMM and there were 562k

SELECT * FROM `oc_notifications_settings` WHERE `user_id` = ?

queries last week.
That is much more calls to the login code than I ever expected.

[provokateurin]

That is much more calls to the login code than I ever expected.

So this change makes sense? I'm not sure I understand what you are trying to imply.

[nickvergessen]

So this change makes sense?

Not sure, I'd prefer to keep it on login, so that users that get their entry dropped recover automatically by some login.

Otherwise we'd need to remove the if ($user->isEnabled()) { check on the background job and that would mean the background job runs millions of queries on some instances.
We could also instead write a user preference whether it's populated, but that could be out of sync with the table then as well.

The main problem is that without this entry, users will not be considered anymore to receive notification reminder emails, which would be rather critical. But we have a listener for creation and it's recovering when opening the settings.
It still gives me a non-satisfying feeling, but as far as I remember, I just wanted to avoid a migration that does a user per query on update. So "should be fine", if you extract the other change from lib/Settings/Personal.php:

This is something else, it needs alignment in BeforeTemplateRenderedListener and the headline of the admin settings needs adjusting too as it's no longer about new users only.

Configure the default notification settings for new users

[nickvergessen]

As per above

[nickvergessen]

Before merging we need to check the query count of the performance test, in case it changed more than just a bit