feat: ajout d’opérations de paramétrage par lots

[dimtrovich]

Description
Ce PR propose d'ajouter des API batch explicites pour stocker et oublier plusieurs paramètres en un seul appel :

• Parametres::getMany()
• Parametres::setMany()
• Parametres::forgetMany()

L'objectif est de prendre en charge les applications et les modules qui disposent déjà d'un groupe de paramètres associés à mettre à jour, sans obliger les appelants à émettre des appels set() ou forget() distincts pour chaque élément.

Cela peut être utile pour les cas courants tels que l'enregistrement de formulaires de configuration, l'application de valeurs par défaut de configuration, la mise à jour des préférences du module, l'importation de paramètres ou la réinitialisation d'un groupe d'options associées. Cela donne également aux gestionnaires un point d'extension clair pour optimiser les écritures groupées tout en gardant compatible le comportement des gestionnaires existants.

Pourquoi

La documentation des limitations indique que les écritures immédiates peuvent entraîner plusieurs requêtes de base de données ou écritures de fichiers lorsque plusieurs paramètres sont modifiés dans une seule requête.

Avec ce PR, les appelants peuvent regrouper directement ces opérations :

parametres()->setMany([
    'app.site_name'  => 'My Great Site',
    'app.site_email' => 'support@example.com',
]);

parametres()->forgetMany([
    'app.site_name',
    'app.site_email',
]);

Les écritures différées optimisent plusieurs appels / tout au long du cycle de vie de la requête, tandis que ces méthodes fournissent une API explicite lorsque l'appelant dispose déjà d'un lot de modifications associées.set()forget()

Comportement

Les nouvelles API suivent le même comportement que les appels répétés à set() et forget() :

• les clés utilisent la syntaxe existante file.property
• les contextes fonctionnent de la même manière
• le comportement de repli de la configuration reste inchangé
• les clés en double sont résolues de manière cohérente, la dernière valeur étant gagnante
• aucune modification du schéma de la base de données n'est requise

Ils respectent également le cadre defer_writes actuel :

• lorsque defer_writes est désactivé, les gestionnaires pris en charge persistent immédiatement le lot
• lorsque defer_writes est activée, les appels par lots sont mis en file d'attente et conservés pendant post_system

Assistance au gestionnaire

BaseHandler implemente par défaut setMany() et forgetMany() qui appellent les méthodes set() et forget() existantes pour chaque élément. Les gestionnaires personnalisés existants continuent de travailler sur cette solution de secours.

Les gestionnaires peuvent toujours remplacer les méthodes par lots lorsqu'elles peuvent persister plus efficacement :

• DatabaseHandler regroupe les insertions par lots, les mises à jour et les suppressions
• FileHandler regroupe les modifications par fichier de contexte

Tests

Ce PR ajoute des tests pour l'API publique, des opérations par lots sensibles au contexte, la gestion des clés en double, la persistance par lots du gestionnaire de base de données/fichiers et les écritures par lots différées.

Liste de contrôle:

• Des commits signés en toute sécurité
• Composant(s) avec blocs PHPDoc, uniquement si nécessaire ou ajoute de la valeur
• Tests unitaires, avec une couverture > 80 %
• Guide de l'utilisateur mis à jour
• Conforme au guide de style