Update monolog/monolog requirement from ^2.9 to ^3.9

[vladislavhmn]

Dependency triage: Update monolog/monolog requirement from ^2.9 to ^3.9

Breaking changes (among others, see full changelog):

Post 3.0:

• BC Warning: Fixed SendGridHandler to use the V3 API as V2 is now shut down, but this requires a new API key
• Deprecated Monolog\Test\TestCase in favor of Monolog\Test\MonologTestCase
• Deprecated Monolog\DateTimeImmutable in favor of Monolog\JsonSerializableDateTimeImmutable
• Deprecated FlowdockHandler & Formatter as the flowdock service was shutdown
• Deprecated CubeHandler and PHPConsoleHandler as both projects are abandoned and those should not be used anymore

2.x -> 3.0:
See UPGRADE notes for details on all breaking changes especially if you are extending/implementing Monolog classes/interfaces.

Noteworthy BC Breaks:

• The minimum supported PHP version is now 8.1.0.
• Log records have been converted from an array to a Monolog\LogRecord object with public (and mostly readonly) properties. e.g. instead of doing $record['context'] use $record->context. In formatters or handlers if you rather need an array to work with you can use $record->toArray() to get back a Monolog 1/2 style record array. This will contain the enum values instead of enum cases in the level and level_name keys to be more backwards compatible and use simpler data types.
• FormatterInterface, HandlerInterface, ProcessorInterface, etc. changed to contain LogRecord $record instead of array $record parameter types. If you want to support multiple Monolog versions this should be possible by type-hinting nothing, or array|LogRecord if you support PHP 8.0+. You can then code against the $record using Monolog 2 style as LogRecord implements ArrayAccess for BC. The interfaces do not require a LogRecord return type even where it would be applicable, but if you only support Monolog 3 in integration code I would recommend you use LogRecord return types wherever fitting to ensure forward compatibility as it may be added in Monolog 4.
• Log levels are now enums Monolog\Level and Monolog\LevelName
• Removed deprecated SwiftMailerHandler, migrate to SymfonyMailerHandler instead.
• ResettableInterface::reset() now requires a void return type.
• All properties have had types added, which may require you to do so as well if you extended a Monolog class and declared the same property.

New deprecations:

• Logger::DEBUG, Logger::ERROR, etc. are now deprecated in favor of the Monolog\Level enum. e.g. instead of Logger::WARNING use Level::Warning if you need to pass the enum case to Monolog or one of its handlers, or Level::Warning->value if you need the integer value equal to what Logger::WARNING was giving you.
• Logger::getLevelName() is now deprecated.

Note: Dependabot checking for major version has been disabled through the attached PRs in the corresponding repos, please reopen PRs to re-enable Dependabot checking should you decide to move on with the update.

Note: monolog might be used on local server or AWS, do the corresponding tests (e.g. one OR the other OR both, as needed)

Acceptance criteria

• Test on Altis local server + Live testing environment on AWS
• Decision if we proceed with upgrade
• Do the Upgrade, or create a new ticket if (a lot) more work is required

For Altis Team Use

Ready for Work Checklist

Is this ticket ready to be worked on? See
the Play Book Definition of Ready

• Is the title clear?
• Is the description clear and detailed enough?
• Are acceptance criteria listed?
• Have any dependencies been identified? (Optional)
• Have any documentation/playbook changes been identified? (Optional)
• Is an estimate or time box assigned?
• Is a priority label assigned?
• Is this ticket added to a milestone?
• Is this ticket added to an epic? (Optional)

Completion Checklist

Is this ticket done? See
the Play Book Definition of Done

• Has the acceptance criteria been met?
• Is the documentation updated (including README)?
• Do any code/documentation changes meet project standards?
• Are automatic tests in place to verify the fix or new functionality?
  • Or are manual tests documented (at least on this ticket)?
• Are any Playbook/Handbook pages updated?
• Has a new module release (patch/minor) been created/scheduled?
• Have the appropriate backport labels been added to the PR?
• Is there a roll-out (and roll-back) plan if required?

[vladislavhmn]

Hey team! Please add your planning poker estimate with Zenhub @wisyhambolu @mikelittle @filter182

[owaincuvelier]

@mikelittle implemented this a few weeks ago:
286e347
but there's a fatal introduced as our another package has been abandoned.
pagevamp/laravel-cloudwatch-logs#46 (comment)

The fatal:

Warning: Undefined array key "HTTP_HOST" in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1335) : eval()'d code on line 45
Fatal error: Declaration of Maxbanton\Cwh\Handler\CloudWatch::write(array $record): void must be compatible with Monolog\Handler\AbstractProcessingHandler::write(Monolog\LogRecord $record): void in /usr/src/app/vendor/maxbanton/cwh/src/Handler/CloudWatch.php on line 164

[mikelittle]

That change was eventually rolled back