chore: safely eliminate future 8.4 deprecation warning

[afilina]

Description

It fixes an incompatibility with PHP 8.4. The code still can't run on 8.x out of the box, but that that change is cross-version compatible and you won't see that deprecation when you eventually upgrade.

RFC: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
Proposed fix: ?T
Can be auto-fixed with PHP_CodeSniffer using the sniff SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue
Result: A TOTAL OF 281 ERRORS WERE FIXED IN 172 FILES.
I manually reviewed each change, especially where FQN is involved (?\DateTime).

Motivation and Context

I stumbled upon this issue as part of my work on PHPCompatibility. Since I already did the work and reviewed the fix, it made sense to open a PR and not waste the effort.

How Has This Been Tested?

• Ran phpcbf with the SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue
• Running phpcs again no longer flags this issue.
• I will rely on the remote CI to confirm this doesn't negatively interact with other static analysis tools, and that tests still pass (sniff auto-fixers are designed to make safe changes).

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:
• Changelog item, see TEMPLATE

Notes about the checklist:

• No new tests are required. This simply makes code future-proof.
• No documentation or changelog is required, since there's no impact on existing behavior and no new feature was added. Dependency bumps also do not ship with any of these.

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[CLAassistant]

All committers have signed the CLA.

[DeepDiver1975]

Thanks a lot for your contribution!

We have currently no plan to support php 8.x .... Long story..... Don't get me started...

I will have a deeper thought on this pr.... My biggest concern is that people might think the code base is now php8 ready, but there is more to be done.

[afilina]

Well composer.json is unabiguous about the target version. We can always discuss what it would take to move things to PHP 8. It's my specialty.

[DeepDiver1975]

We can always discuss what it would take to move things to PHP 8.

It first needs decision and a plan by people in charge .... this is a painful topic over the past years .....

In case you are interested what is takes to bring owncloud to php8: #40981

For the time being I will close this PR because of given reasons - Thank you!

[afilina]

No worries. I know how hard these upgrades can be. Let me know if there is renewed interest. As I said, upgrades of large and complex projects to PHP 8 is my specialty. Sometimes I even upgrade from PHP 4.

I'm not sure what to take away from the linked thread. Is this an issue of not having the time to see the upgrade through, or is the long-term plan to abandon this repo in favor of infinite scale?