Modernize code

[sukhwinder33445]

Modernize and clean up the codebase by adopting the latest PHP features and functions.

Changes made:

• Add data types for properties, parameters, and method return values
• Remove the unnecessary InAndNotInUtils trait, as it was only introduced to reduce phpstan errors
• Replace switch statements with match expressions where possible

requires Icinga/ipl-stdlib#63 (The signature of limit() and offset() methods in Cursor and LimitOffsetInterface must be compatible with ipl\Stdlib\Contract\Paginatable)

[BastianLedererIcinga]

The InAndNotUtils trait is currently incompatible with ipl\Stdlib\Filter\Condition.

[BastianLedererIcinga]

The rest looks good.

The base branch was changed.

[BastianLedererIcinga]

Local unit tests all pass when using the other modernize branches.

[BastianLedererIcinga]

Looks good, tests all pass with Icinga/ipl-stdlib#63. Icinga\Module\Reporting\RetryConnection should be the only dependency.

[sukhwinder33445]

I created Icinga/icingaweb2-module-reporting#269 to add the required change in sub-class.

[lippserd]

requires Icinga/ipl-i18n#26 (for tests to run, compatibility issue)

Why? ipl-i18n is not a dependency of either ipl-sql or ipl-stdlib.

---

77124d2 states "non-breaking", but it does introduce strict types on Cursor::limit() and Cursor::offset(), which requires a newer version of ipl-stdlib. Plus, the changes only become testable through follow-up commits, which spreads related changes across multiple places and makes it harder to reason about the impact.

To keep things manageable especially with all the releases coming soon, it helps if we follow a few rules:

When we say non-breaking, we mean it: no dependency or consumer must need to change. Any test adjustments belong in the same commit, and if a newer PHP version is needed, composer.json should reflect that in the same commit with a note in the description.

When a change in an IPL component does require updates in consumers,
those consumer updates should land in a single commit that also bumps the version constraint in composer.json.
Since we don't have releases yet, pointing to a branch is totally fine:
ipl-i18n#13 is a good example of how to do that.
We'll change those to proper version constraints once we actually release.

In the end, we're aiming for two distinct release steps:

• first a non-breaking IPL release that's safe for Icinga Web and its modules,
• then a follow-up breaking release that coordinates updates across everything affected.

Clean, self-contained commits are important.

One more thing worth clarifying: breaking changes that only affect IPL don't need to live in a separate PR as long as the commits are self-contained.
However, anything that breaks Icinga Web and/or its modules does need to go into a new PR.

@BastianLedererIcinga @Jan-Schuppik Please check your PRs to make sure they comply with these rules. I've already adjusted Icinga/ipl-stdlib#63.

[sukhwinder33445]

I have adjusted the commits accordingly. Each commit is now self-contained.