Move _dblog_get_message_types and dblog_filters to a DbLogFilters service and deprecate them

I haven't really looked at this thoroughly, but the underscore one is meant to be private and by putting it in a service we're effectively making it API. Wonder if a trait with protected methods might be better? Feel free to disagree, because I really only briefly looked at this.

Correct me if I'm wrong @mstrelan think he was saying _dblog_get_message_types() was meant to be private and now via a service it's not so much.

But even though it was intended to be private nothing was really preventing it from being called really right? Personally I don't see a reason to not be a service API but also think it could be a trait as mentioned. Probably doesn't help much move this forward lol

Still think it's weird to expose these but not concerned enough about it. Left some suggestions anyway. Leaving the status as NR because you can also just skip the suggestions if you prefer.

Actually one of the CR links is wrong, back to NW.

One of the deprecation errors is copy/pasta from another issue and needs an update. Otherwise, this looks RTBC to me. The rest of the diff seems fine, I didn't spot anything else that needed improving.

Thanks!
-Derek

It seems every-so-slightly weird that getMessageTypes() is a method on a service called DbLogFilters, since in theory you might want the list of distinct types for something other than filtering. But after looking around core/modules/dblog/src, I'm not seeing much of an alternative. Definitely doesn't seem worth 2 distinct services for these. 😬 Willing to call this Good Enough(tm) for now.

I don't see anything else to complain about int he MR diff. Minor updates to the summary and title. Latest pipelines are all green.

RTBC!

Thanks again,
-Derek

Nice to see this finally solves #2852990: Deprecate dblog_filters +1 from my side as well.

The only thing is not 100% clear to me is if this effort shouldn't also include an interface... Or mark this service as `@internal`. If not The new API has the same problems we had with dblog_filters. See #582622: provide hook for dblog_filters

Was on the fence as to whether this should be a service or just a trait, it is hard to call - would anyone really need to swap this out? But ultimately it makes little difference and this is the easier conversion.

Once we have things like #3558306: Support automatic setter injection using the #[Required] attribute in AutowireTrait/AutowiredInstanceTrait it'll be possible to autowire traits via setter injection and otherwise keep them standalone, but I'm not sure yet if that's a pattern we should be encouraging.

Added some review comments.

I don't have anything to add to the review. I checked the commits since @dww RTBC'ed it. They look good to me.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Post-bot-rebellion rebase

Was also on the fence whether this should be removed in 12 or 13, but given there is some kind of public API here let's just stick with 13.

Committed and pushed 51c8bbe6a6b to main and dc71ae5f169 to 11.x. Thanks!