Add triggers for stream connectors

[tanguyvda]

Description

grant the possibility for users to add triggers in a dedicated file.
During stream connector life cycle, they are fired by the stream connector.
This is made to allow even more behavior customization for users

Update CI to test the stream connectors with the updated library.

Type of change

• Patch fixing an issue (non-breaking change)
• New functionality (non-breaking change)
• Breaking change (patch or feature) that might cause side effects breaking part of the Software

Target serie

• 24.04.x
• 24.10.x
• 25.10.x
• master

How this pull request can be tested ?

Please describe the procedure to verify that the goal of the PR is matched. Provide clear instructions so that it can be correctly tested.

Any relevant details of the configuration to perform the test should be added.

Checklist

Community contributors & Centreon team

• I have followed the coding style guidelines provided by Centreon
• I have commented my code, especially new classes, functions or any legacy code modified. (docblock)
• I have commented my code, especially hard-to-understand areas of the PR.
• I have rebased my development branch on the base branch (master, maintenance).

[tuntoja]

Hi @tanguyvda, a heads-up before this PR is merged: it overlaps with #409 and #410 (MON-205723). Those two move stream-connectors to the new tag-based release workflow, the same one already used by centreon-plugins and centreon-plugin-packs. Nothing needs to change in the Lua code; only the CI wiring and the lib version are concerned.

What #409 / #410 change

• Releases no longer go through master. release-new tags the release branch (centreon-stream-connectors-YYYYMMNN), and pushing that tag promotes testing to stable on Pulp and JFrog.
• Each packaging workflow reacts to the tag. stream-connectors.yml, stream-connectors-lib.yml and lua-*.yml each get push: tags: ['centreon-stream-connectors-[0-9]+'] and a promote job. On a tag, a workflow is skipped when none of its on.push.paths changed since the previous release tag.
• ci(release): read package versions from root version files #410 moves the fixed versions out of the workflows, into root files: .version.stream-connectors-lib and .version.lua-*.
  • Connectors are versioned with the release number in .version.stream-connectors.
  • release-new refuses a release when a package's code changed without a higher version.

Where it collides with this PR

1. Lost tag trigger. Here, stream-connectors.yml and stream-connectors-lib.yml become workflow_call only, so they would no longer receive the release tag push. The connectors and the lib would never be promoted to stable. The lua-* packages are not affected.
2. Textual conflicts. Both sides edit the same on: blocks and the lib's package step (version: "3.8.1" becomes .version.stream-connectors-lib in ci(release): read package versions from root version files #410).
3. The bump check in ci(release): read package versions from root version files #410. It finds each package's files through the workflow that lists its .version.* file. With the lib paths and the connectors paths in the same orchestrator, a connector-only change would look like an unbumped lib change.
4. The lib version. This PR changes the library (sc_trigger, sc_storage, sc_flush, …). The 20261000 release ships the lib as 3.8.2 (add more keywords to params to hide list #380, add new param drop_events_on_send_failure #388, fix issue when host/service not found in cache when receiving downtime #393), so this one needs a higher version, for example 3.9.0 since it adds a feature.

How to combine them, whichever merges first

• The release tag trigger moves to stream-connectors-ci.yml. Its detect-changes job already has lib and connectors filters.
  • On a release tag, it diffs from the previous release tag instead of github.ref, and calls only the workflow(s) that changed.
  • Each called workflow then runs its promote job.
• The bump check reads an explicit package list instead of the workflow paths. I'm changing that in ci(release): read package versions from root version files #410 so it works in both merge orders.
• The lib goes to 3.9.0. Set it in .version.stream-connectors-lib if ci(release): read package versions from root version files #410 is already merged; otherwise ci(release): read package versions from root version files #410 will set it when rebased.
• Who adapts what:
  • if this PR merges first, I rebase ci(release): promote stream-connectors to stable on release tag push #409 / ci(release): read package versions from root version files #410 on it;
  • if ci(release): promote stream-connectors to stable on release tag push #409 / ci(release): read package versions from root version files #410 merge first, I can push the adaptation to this branch or open a follow-up PR, whichever you prefer.

Either order works; we only need to avoid merging this PR unchanged after #409 / #410 without the trigger move. Happy to go through it together.

[tuntoja]

@pkippes @sdepassio one packaging point outside the diff:

Every certified connector now does require("centreon-stream-connectors-lib.sc_trigger"), but the lib version is unchanged (3.8.1 in stream-connectors-lib.yml, already released) and the connectors still depend on centreon-stream-connectors-lib >= 3.8.0 / (>= 3.8.0~) in packaging/connectors/centreon-stream-connectors.yaml.

Example: a poller with lib 3.8.1-1 and centreon-stream-kafka-20260811-1 runs dnf update. The connector upgrades (date version is always newer), the lib doesn't (same 3.8.1-1 is already installed), and the dependency is still satisfied. Broker then fails to load the output with module 'centreon-stream-connectors-lib.sc_trigger' not found. CI doesn't catch it because connectors are tested against the lib built in the same run.

Could we:

• bump the lib to 3.9.0 (new module);
• raise the connectors' floor to >= 3.9.0 / (>= 3.9.0~).