refactor(apps): Use constructor property promotion when possible

[provokateurin]

Summary

Done with rector. Maybe this PR is a bit too big, I can make separate PRs for individual apps if needed.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[ChristophWurst]

Checked apps/dav and some other random samples. Can't see any issues

[nickvergessen]

In terms of backporting I'm a fan of not doing it, unless it's touched anyway 🙈
But of course clean code is also fine and resolving the conflict should be doable

[provokateurin]

I would not backport this, I tried to apply it locally and there are too many conflicts that are not worth spending the time on.

[nickvergessen]

• Psalm has some comments
• the one thing I wonder is in some cases we type hint the member to an actual implementation, while the injection is done with the public interface, because not all methods are in the public interface. Of course I don't know a place out of my head, but do you know how it handles that?

[provokateurin]

As far as I can tell it just removes the property and adds the promotion in the constructor. That means if the injection uses the interface we will also use that internally. Judging from the failed tests and the psalm results this doesn't seem to cause problems with every used method already being in the interface (which is really good 🎉)

[provokateurin]

Only problem I found was where the property was called uid which was then renamed in the constructor as well, so it was no longer userId and could not be resolved.