feat(settings): Add setup check for too much caching

[ChristophWurst]

• Resolves: [Bug]: A user accesses the administrator account without doing anything special. #40863 (or at least would help detect this type of configuration mishap and various others)

Summary

Warn admins if their server caching is caching responses that should not be cached.

The approach is simple:

• Two requests with the same URL
• Make sure there is a Set-Cookie response header
• Return something unique, so uniqueness of the responses can be checked

If the two responses are identical, then the server didn't process the requests individually.

TODO

• Code
• Testing

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)

[nickvergessen]

timefactory? :D

[ChristophWurst]

the constructor has like 37 injected services and I didn't want to touch that beast

[ChristophWurst]

I can't get my local nginx to cause the issues reported in #40863. When I turn on asset caching, all resources give an HTTP404.
@joshtrichards were you able to reproduce the issue yourself?

Edit: set up nginx proxy manager for my dev env. Even with asset caching I'm not able to trigger a cached response that has set-cookie headers.

[joshtrichards]

Edit: set up nginx proxy manager for my dev env. Even with asset caching I'm not able to trigger a cached response that has set-cookie headers.

I haven't managed an account takeover yet, but with NPM + their Cache Assets enabled there are behavior changes that are red flags:

• if I use Web Files and trigger a WebDAV GET (e.g. /remote.php/dav/files/ncadmin/Photos/Nextcloud%20community.jpg) by using Download it'll download the first time in the browser then subsequent additional download requests of the same image will trigger a basic auth popup (session cookie rotation on the Nextcloud side and the cache ignoring it?)
• if I cURL that same WebDAV URL after the browser download, I get the same cookie as appears in the browser (!) and the cookies don't change ever again (!) for subsequent cURL requests of that URL [doesn't matter I'm not providing any authentication information to cURL hah]
• random in-browser log-outs out of nowhere occur (might be the source of some of the mysterious recurring session management and log-in/log-out problems that get reported or pop up on the forum)
• I can replicate issues like [Bug]: TypeError: OCA\UserStatus\Controller\UserStatusController::__construct() Argument #3 ($userId) must be of type string, null given #42156

As soon as I turn off NPM's caching things go back to normal and I can't replicate any problems. Some of these behaviors seem to be timing specific and/or depend on which session connected first (which makes sense intuitively).

I think a strong generic inappropriate caching check is a good idea for us.

This type of caching contradicts our recommended config and randomly appears to breaks stuff. That's enough for me to justify a check.

Asides:

• Probably also introduces security problems (account takeovers like [Bug]: A user accesses the administrator account without doing anything special. #40863 and/or inappropriate protected asset access). I have yet to demo that firsthand, but given another cup of coffee or two the evidence suggests that being possible (though we may have enough countermeasures on our side these days that it's more challenging than it appears; not sure it even matters give the breakage introduced already).
• I can't figure out the intended use case for NPM's Cache Assets option. It is too aggressive for both public and private caching IMO. And it's not documented anywhere I can find (and no original PR; it was brought in through the original initial commit). I suspect most people just activate it thinking "Caching = better performance!"