TYPO3 Core

We're seeing an excessive amount of set_no_cache triggered warnings, caused by setting no_cache.

See the code in question here:
https://github.com/TYPO3/typo3/blob/main/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php#L2404

After having looked through the issue history around this feature, I've found no real discussion around why this is logged as a WARNING as opposed to just a NOTICE (which could be reasonably suppressed in production). Therefore I'm submitting this, if nothing else then to understand the basis for this.

Short summary:
TYPO3 will, when set_no_cache is called, issue a log WARNING that contains either a caller provided reason for why it was called or alternatively a pointer to what code called it, generated by calling the backtrace function.
In addition to the plain set_no_cache logging case, there is also the related but somewhat separate "disableNoCacheParameter" handling that logs as a WARNING if set_no_cache is logged, but is ignored by the [TYPO3_CONF_VARS][FE][disableNoCacheParameter]. This also triggers a WARNING.

Argument:
Essentially I believe this is overuse of WARNING. While triggering these logs certainly is an indicator of bad design, this is not universally the case. It seems much more sane to simply log this as a notice, so that people can enable it when needed, which would mostly be during development or during debugging.

Alternatively one could of-course provide the means to suppress these logs, but that feels like excessive configurability. The logging system has a logtype designed for this type of thing, and I believe that is a NOTICE in this case.

Also, changing the log type to NOTICE would also allow us to deprecate the ugly "internal" variable, which does exactly what I'm suggesting for internal calls, and which seems like mis-design to have on a public function.