Deprecate support for unused \PDO::FETCH_* modes

My big worry with this change is that it will break (in Drupal 11) existing sites. I know that is allowed. Only we must be very sure that everything that we should allow is not deprecated in this issue.

1. +++ b/core/lib/Drupal/Core/Database/StatementWrapper.php
   @@ -9,6 +9,24 @@
   +  protected array $fetchModes = [
   +    \PDO::FETCH_DEFAULT => 'FETCH_DEFAULT',
   +    \PDO::FETCH_LAZY => 'FETCH_LAZY',
   +    \PDO::FETCH_ASSOC => 'FETCH_ASSOC',
   +    \PDO::FETCH_NUM => 'FETCH_NUM',
   +    \PDO::FETCH_BOTH => 'FETCH_BOTH',
   +    \PDO::FETCH_OBJ => 'FETCH_OBJ',
   +    \PDO::FETCH_BOUND => 'FETCH_BOUND',
   +    \PDO::FETCH_COLUMN => 'FETCH_COLUMN',
   +    \PDO::FETCH_CLASS => 'FETCH_CLASS',
   +    \PDO::FETCH_INTO => 'FETCH_INTO',
   +    \PDO::FETCH_FUNC => 'FETCH_FUNC',
   +    \PDO::FETCH_NAMED => 'FETCH_NAMED',
   +    \PDO::FETCH_KEY_PAIR => 'FETCH_KEY_PAIR',
   +    \PDO::FETCH_CLASS | \PDO::FETCH_CLASSTYPE => 'FETCH_CLASS | FETCH_CLASSTYPE',
   +    \PDO::FETCH_CLASS | \PDO::FETCH_PROPS_LATE => 'FETCH_CLASS | FETCH_PROPS_LATE',
   +  ];
   

   Can we add a comment with were we could the values from. For better maintainability and documentation.

2. +++ b/core/lib/Drupal/Core/Database/StatementWrapper.php
   @@ -193,6 +211,14 @@ public function rowCount() {
   +    if (isset($mode) && !in_array($mode, [
   +      \PDO::FETCH_ASSOC,
   +      \PDO::FETCH_COLUMN,
   +      \PDO::FETCH_NUM,
   +      \PDO::FETCH_OBJ,
   +    ])) {
   

   Why are only those 4 settings allowed. Could you explain for all 3 methods were they are added.

The testbot is failing with over 300 fails.

This issue also needs to look at what is used in contrib - starting with core is fine but we need to search contrib for all the modes we decide to not support.

Could a CR be written for this?

Change looks good and assuming since nothing broke (test wise) that additional tests aren't needed?

CR LGTM

All code changes look good to me.
The IS and the CR are in order.
For me it is RTBC.

Re #4/#5 there doesn't seem to be any discussion of which modes we should actually support, nor any evidence that the deprecated modes are not used in contrib. It would at least be good to know we aren't entirely disrupting something widely used in contrib, if we are dropping these with no replacement.

I searched contrib and could not find uses of FETCH_DEFAULT, FETCH_LAZY, FETCH_BOUND, FETCH_INTO, FETCH_NAMED, FETCH_FUNC or FETCH_CLASSTYPE.

FETCH_BOTH is used by excel2webpage and w3c_validator.

FETCH_KEY_PAIR is used by gtfs.

I suspect that all these usages could be replaced by a different fetch option and as there are only three I am not particularly worried about this change any longer.

I use http://grep.xnddx.ru/ which seems to be updated every few weeks, and has been more reliable for me.

GitLab search is also available, which in this case brings up a different contrib module plus some false positives in vendor code: https://git.drupalcode.org/search?scope=blobs&search=FETCH_KEY_PAIR&grou...

Haven't reviewed this in enough depth to commit it, but general +1 to reducing the surface area here. I had a quick look at the three usages @longwave found. FETCH_BOTH looks like it's unnecessary and they could switch to more or less any of the standard ones. FETCH_KEY_PAIR would require a bit of refactoring, but reasonable to require that for a major release given it's a single usage.

I'm triaging RTBC issues.

I looked at this late last night and after reading the IS and comments I don't see anything left to do. There may be a follow up for project gtfs per #19.

Leaving at RTBC.

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 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.

This looks great.

As discussed above, there are 3-4 contrib modules affected by the deprecations, and they can probably just switch to a different fetch mode and be fine. Worst case we could undeprecate one or two if there's a really good reason to use them.