Add Sentry BreadcrumbHandler support

[HypeMC]

Adds support for getsentry/sentry-php#1199.

monolog:
  handlers:
    sentry:
      type: sentry
      hub_id: Sentry\State\HubInterface
      level: !php/const Monolog\Logger::ERROR
    sentry_breadcrumb:
      type: sentry_breadcrumb
      sentry_handler: sentry
      level: !php/const Monolog\Logger::INFO

# or if you don't have Sentry bundle installed

monolog:
  handlers:
    sentry:
      type: sentry
      dsn: "https://public@sentry.example.com/1"
      level: !php/const Monolog\Logger::ERROR
    sentry_breadcrumb:
      type: sentry_breadcrumb
      sentry_handler: sentry
      level: !php/const Monolog\Logger::INFO

Initially, I considered using the existing handler option instead of introducing the new sentry_handler option. However, I decided against it because the PSR logger doesn't get auto-enabled when the handler option is used:

monolog-bundle/DependencyInjection/MonologExtension.php

Lines 179 to 183 in ed0e4a2

	if (null === $handler['process_psr_3_messages']['enabled']) {
	$handler['process_psr_3_messages']['enabled'] = !isset($handler['handler']) && !$handler['members'];
	}

[GromNaN]

Initially, I considered using the existing handler option instead of introducing the new sentry_handler option. However, I decided against it because the PSR logger doesn't get auto-enabled when the handler option is used

Should we make an exception for sentry_breadcrumb and always enable the the process_psr_3_messages handler?
Using both handler and sentry_handler with type: sentry_breadcrumb would not make sense, does it?

[stof]

We already have a handler setting used by all handlers that are wrapping another handler to configure which one it is. It should be reused inside of adding a new setting.

[stof]

I don't think we should add support for third-party Monolog handlers in MonologBundle itself, as this will become unmaintainable:

• how do we decide which one we implement ?
• how do we deal with potential BC breaks in those packages for which we have no composer requirements ?

We already support type: service to allow defining a service yourselves and then using it as handler (potentially injected into other handlers), which is the way to support community handlers

[GromNaN]

The integration with the 3rd party library was added by #313. Either we decide to deprecate it in 3.x and remove it in 4.x, or we manage to integrate the features. I prefer the first solution for the rasons you exposed, but we need an upgrade path for users.

Edit: The documentation of the SentryBundle use the type: service configuration.
https://docs.sentry.io/platforms/php/guides/symfony/logs/

[HypeMC]

I agree that it makes sense not to support 3rd-party handlers. Sentry's is currently the only one, so it's an oddball.

However, I don't think 3rd-party handlers are the only issue. For example, this handler seems to be broken:

case 'rollbar':
    if (!empty($handler['id'])) {
        $rollbarId = $handler['id'];
    } else {
        $config = $handler['config'] ?: [];
        $config['access_token'] = $handler['token'];
        $rollbar = new Definition('RollbarNotifier', [
            $config,
        ]);
        $rollbarId = 'monolog.rollbar.notifier.'.sha1(json_encode($config));
        $rollbar->setPublic(false);
        $container->setDefinition($rollbarId, $rollbar);
    }

    $definition->setArguments([
        new Reference($rollbarId),
        $handler['level'],
        $handler['bubble'],
    ]);
    break;

The RollbarNotifier class doesn't exist in the current version of the rollbar/rollbar library, and Monolog v3's RollbarHandler doesn't support it either. I think referencing any 3rd-party classes in the code could lead to potential BC breaks, so maybe all of this should be removed?

[stof]

@HypeMC this is because this code is related to support of the Monolog RollbarHandler of older versions of Monolog (which we'll be able to clean in 4.0).
Monolog itself has a policy to not accept new handlers in core that require third-party dependencies. But I think that we should keep support for those handlers in MonologBundle as long as they are part of Monolog itself.

[HypeMC]

@stof Yes, we should keep support for the handlers themselves. I was thinking we could maybe drop support for registering the 3rd-party classes and just keep the option of providing the service ID (in other words, drop the else part from my previous example).

[HypeMC]

Closing this one as we don't want to support third party handlers.