Nullable parameter after attribute incorrectly tokenized as ternary operator

[mhlsf]

Describe the bug
On a method with a PHP 8 attribute before a nullable parameter, cs if forcing to have a space after the ? of a nullable the nullable parameter

Code sample

public function setDefault(#[ImportValue(
        column: 'Material by default',
        transformer: YesNoBooleanTransformer::class,
        constraints: [
            [
                Assert\Type::class,
                ['type' => 'bool'],
            ],
        ]
    )] ?bool $value = null): void
    {
        $this->setBool('default', $value);
    }

To reproduce
Steps to reproduce the behavior:

1. Create a file called test.php with the code sample above...
2. Run phpcs test.php ...
3. See error message displayed

 451 | ERROR | [x] Expected at least 1 space after "?"; 0 found
     |       |     (PSR12.Operators.OperatorSpacing.NoSpaceAfter)
 451 | ERROR | [x] Parameter $value has null default value, but is not marked as nullable.
     |       |     (SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue.NullabilityTypeMissing)

Expected behavior
We should be able to put a nullable parameter after a PHP 8 parameter attribute. Here cs is confusing the PHP8 attribute and the bool as a ternary operator, thus forcing the space after the "?" causing the "Parameter $value has null default value" because this work fine :

public function setDefault(#[ImportValue(
        column: 'Material by default',
        transformer: YesNoBooleanTransformer::class,
        constraints: [
            [
                Assert\Type::class,
                ['type' => 'bool'],
            ],
        ]
    )] ? bool $value): void
    {
        $this->setBool('default', $value);
    }

Versions (please complete the following information):

• PHP: 8.0
• PHPCS: 3.5
• Standard: PSR2, PSR12, MySource, PSR1, Squiz, PEAR, Zend, Doctrine and SlevomatCodingStandard

[jrfnl]

@mhlsf Thank you for reporting this with a usable code sample. I've been able to reproduce this and have submitted PR #3446 to fix this. If you have the chance, testing appreciated.