Pull Request in continuation of gh-39123

Summary of Changes

• Updated the method signature of \Joomla\CMS\Log\DelegatingPsrLogger::log to match psr/log version 3
• Introduce \Joomla\CMS\WebAuthn\Server to abstract the common WebAuthn code and update implementation (system and multifactorauthentication plugins) with it.
• Made the \Joomla\CMS\Log\DelegatingPsrLogger class final and internal.

Testing Instructions

• Check out the 5.0-dev branch
• Run npm ci
• Run composer install
• Try to install and use a Joomla 5.0-dev site on PHP 8.1

Actual result BEFORE applying this Pull Request

• You cannot access the site due to a PHP error about the declaration of \Joomla\CMS\Log\DelegatingPsrLogger::log
• If you patch the previous problem, Web Authentication does not work either for logging in or for Multi-factor Authentication

Expected result AFTER applying this Pull Request

• The PHP error is gone
• You can use Web Authentication for logging in and for Multi-factor Authentication

Link to documentations

Please select:

• No documentation changes for docs.joomla.org needed

• Pull Request link for manual.joomla.org: PR 62

Technical details

BACKWARDS INCOMPATIBLE CHANGE (PRE-EXISTING TO THIS PR). psr/log version 3 has changed some signatures, most importantly that of the log method. Any third party extension implementing a PSR logger will break following the update of PSR-3 in Joomla. I can tell you upfront that this already affects my own software and I have to fork psr/log v1 for use in my extensions. Noted in manual PR 62.

Fixing that would require forking the WebAuthn library, as I had said in #38209 (comment). This is the exact problem described in https://medium.com/@davert/why-i-dont-enjoy-writing-php-anymore-aee8a85ca8aa So, no matter what we do we will have a major problem: either we break b/c in software which is (correctly) using PSR-3 for logging, or we have to maintain a fork of a third party library. This is a fundamental problem of PHP which I had foreseen circa 2015, when PHP 7 introduced major b/c breaks.

Another workaround is to change the namespace of specific dependencies and their dependencies as I have described in https://www.dionysopoulos.me/book/advice-composer.html under “Dealing with namespace clashes and older dependency versions included with Joomla”. However, this is essentially the same as maintaining a fork with the asterisk that the fork is an automated process. The big caveat is we'd be relying on Yet Another Third Party Software (PHP-Scoper) and introduce one more convoluted step in the build process with everything that entails. The phrase "damned if you, damned if you don't" comes to mind.

Why did we introduce a WebAuthn Server class? The WebAuthn library decided to remove the Server class for reasons unknown. This would have led us to duplication of very convoluted code with a very high chance of introducing bugs now and in the future. Instead, I chose to reimplement the Server class (most of its code was already overridden in Joomla 4.2 with our custom code anyway) as a CMS library class and mark it BOTH final AND @internal to indicate that it is not part of the public Joomla API which is bound by the Joomla b/c promise. The only thing we can promise about this class is that it will change when we upgrade the WebAuthn library to version 5.