Filtering access-errors.log entries

[cedric-anne]

In GLPI 11.0, all the 4xx errors, except errors related to API endpoints, are logged in the access-errors.log file introduced in #11996 in GLPI 10.0.2, including 400/404 errors resulting from an access to an invalid URL. In GLPI 10.0, most of them were not logged, as there were no centralized error handling.

Each error is logged with its trace, e.g.:

[2025-01-30 09:29:08] User ID: `2` tried to access a non-existent item on `/lib/gridstack-extra.css?v=1f7aecc15cfb7a2618b010728d4a110c9756a7af`.
  Additional information: No route found for "GET http://127.0.0.1:8091/lib/gridstack-extra.css" (from "http://127.0.0.1:8091/front/central.php")
  Backtrace :
  .../event-dispatcher/Debug/WrappedListener.php:116 Symfony\Component\HttpKernel\EventListener\RouterListener->onKernelRequest()
  ...ymfony/event-dispatcher/EventDispatcher.php:220 Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke()
  ...symfony/event-dispatcher/EventDispatcher.php:56 Symfony\Component\EventDispatcher\EventDispatcher->callListeners()
  ...spatcher/Debug/TraceableEventDispatcher.php:139 Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
  vendor/symfony/http-kernel/HttpKernel.php:157      Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch()
  vendor/symfony/http-kernel/HttpKernel.php:76       Symfony\Component\HttpKernel\HttpKernel->handleRaw()
  vendor/symfony/http-kernel/Kernel.php:197          Symfony\Component\HttpKernel\HttpKernel->handle()
  public/index.php:56                                Symfony\Component\HttpKernel\Kernel->handle()
  Previous: No routes found for "/lib/gridstack-extra.css/".
  vendor/symfony/routing/Matcher/UrlMatcher.php:97   Symfony\Component\Routing\Matcher\CompiledUrlMatcher->match()
  vendor/symfony/routing/Router.php:237              Symfony\Component\Routing\Matcher\UrlMatcher->matchRequest()
  ...ttp-kernel/EventListener/RouterListener.php:105 Symfony\Component\Routing\Router->matchRequest()
  .../event-dispatcher/Debug/WrappedListener.php:116 Symfony\Component\HttpKernel\EventListener\RouterListener->onKernelRequest()
  ...ymfony/event-dispatcher/EventDispatcher.php:220 Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke()
  ...symfony/event-dispatcher/EventDispatcher.php:56 Symfony\Component\EventDispatcher\EventDispatcher->callListeners()
  ...spatcher/Debug/TraceableEventDispatcher.php:139 Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
  vendor/symfony/http-kernel/HttpKernel.php:157      Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch()
  vendor/symfony/http-kernel/HttpKernel.php:76       Symfony\Component\HttpKernel\HttpKernel->handleRaw()
  vendor/symfony/http-kernel/Kernel.php:197          Symfony\Component\HttpKernel\HttpKernel->handle()
  public/index.php:56                                Symfony\Component\HttpKernel\Kernel->handle()

IMHO, logging 4xx errors is not really usefull. This logging was introduced to help people to understand why their request was refused. I guess we can avoid this problem by displaying more relevant messages. In most cases, having the trace of the error will not really help, as it will just point to the expected Session::checkRight() usage.