Introduce new type-safe methods for receiving config section values

[sgiehl]

Description

This changes the section config helpers to support typed access with optional typed defaults, and updates existing manual-cast call sites to use those helpers while preserving previous behavior.

What changed

SectionConfig now provides typed getters for config values:

• getIntegerConfigValue(string $name, ?int $default = null, ?int $idSite = null): ?int
• getFloatConfigValue(string $name, ?float $default = null, ?int $idSite = null): ?float
• getBoolConfigValue(string $name, ?bool $default = null, ?int $idSite = null): ?bool
• getStringConfigValue(string $name, ?string $default = null, ?int $idSite = null): ?string
• getArrayConfigValue(string $name, ?array $default = null, ?int $idSite = null): ?array

Behavior:

• If the config value is missing, the typed default is returned.
• If the value cannot be cast to the requested type, a warning is logged and the typed default is returned.
• If no default is provided, null is returned.

TrackerConfig was refactored to extend SectionConfig, while keeping the use_third_party_id_cookie special handling.

Existing call sites that previously did manual casts on GeneralConfig, DatabaseConfig, or TrackerConfig were updated to use the typed getters instead. Where the old code relied on PHP cast fallback behavior, explicit defaults were added so behavior stays the same:

• old (int) casts now pass 0
• old (bool) / !! casts now pass false
• old (string) casts now pass ''

Why

This avoids repeating ad-hoc casts throughout the codebase, makes the expected type explicit at the config access point, and centralizes invalid-value handling and logging.

Notes

The migrated call sites were reviewed to preserve previous semantics. In particular, places that previously depended on PHP cast behavior now pass explicit defaults instead of implicitly returning null.

Checklist

• [✔] I have understood, reviewed, and tested all AI outputs before use
• [✔] All AI instructions respect security, IP, and privacy rules

Review

• Functional review done
• Potential edge cases thought about (behaviour of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• New documentation added or existing documentation updated

[caddoo]

A nice change, just a comment.

How can we encourage using the specially typed functions though going forward?

And move away from people using getConfigValue

[sgiehl]

@caddoo I considered marking the method as @deprecated, but that would actually be wrong. There might be rare cases where using that method would still be needed. Like if e.g. the type could be an array or a string value.
I've now added a comment to the method, that using the type safe variants should be preferred. Hopefully that will cause at least the AI to follow the suggestion 🙈