mk_sap: Add exclude_paths option to skip monitoring objects

[Simon0Harms]

General information

This concerns the mk_sap agent plugin (cmk/plugins/sap/agents/mk_sap.py),
which collects monitoring data from SAP R/3 / S/4HANA systems via RFC calls
against the SAP CCMS monitoring infrastructure (RZ20 monitor trees). Which
parts of the CCMS tree are collected is controlled by the monitor_paths
option in /etc/check_mk/sap.cfg, a list of unix shell patterns matched
against the full path of each monitoring object.

Setup where this came up: S/4HANA system monitored via mk_sap with

monitor_paths += [
    'SAP CCMS Technical Expert Monitors/All Monitoring Contexts/Critical Number Ranges/*',
]

The "Critical Number Ranges" monitor warns before SAP number ranges run
full — valuable for business objects, since a number range overflow stops
production. However, the same subtree also contains alert containers for
purely technical number ranges such as ALAUTOUID (package SMOI, UIDs for
CCMS data suppliers). This number range is rolling by design with a
warning threshold of 25% remaining, so it periodically produces WARN
alerts that cannot be acted upon — permanent noise in the resulting
logwatch service.

Proposed changes

What is the expected behavior?
It should be possible to use a wildcard monitor_paths rule (to keep
automatic pickup of new nodes, which is important for number range
monitoring where new critical objects appear dynamically) while skipping
individual known-noisy objects below it.

What is the observed behavior?
monitor_paths is a pure allow list; there is no exclude mechanism. The
only workarounds are to enumerate all wanted sibling nodes explicitly
(losing auto-discovery) or to disable alert generation in the SAP system
itself (RZ20/RZ21), which affects all CCMS consumers, not just Checkmk.

In what way does the patch change the current behavior?
It introduces an exclude_paths option (default: empty list) using the
same unix shell pattern syntax as monitor_paths. A path matching any
exclude pattern is skipped, even if it matches a monitor_paths pattern.
Configurations that do not set exclude_paths keep the exact previous
behavior — all pre-existing unit tests pass unchanged.

Design note on toplevel matching: When deciding whether a whole monitor
tree is fetched via RFC, monitor_paths rules are shortened to their
first two path segments. Exclude rules are intentionally not
shortened and are always matched against the full path: shortening a rule
which targets a single subtree node would exclude the whole monitor
instead of just the node. A rule matching the toplevel path itself still
skips the whole monitor and saves the RFC calls for its tree.

Documentation note: Path segments are built from the 40 character SAP
field MTNAMESHRT, so long node names arrive truncated (e.g.
Client 000 Alert Messages for Number Ran) and patterns have to match
the truncated name. The sample config documents this, including a pointer
to the debug output line in the plugin for verifying exact paths.

Example configuration (from the updated sample config
agents/sap/sap.cfg):

exclude_paths += [
    'SAP CCMS Technical Expert Monitors/All Monitoring Contexts/Critical Number Ranges/Critical Number Ranges All Clients/Client 000 Alert Messages for Number Ran*',
]

Unit tests:
tests/unit/cmk/plugins/sap/agents/test_mk_sap.py gains a parametrized
test for to_be_monitored() with 7 cases. The cases covering the new
behavior fail without the patch; the cases covering the unchanged default
behavior pass before and after. Covered: exclude precedence over a
matching monitor rule, sibling nodes (other clients) staying monitored,
subtree excludes not skipping the whole monitor during toplevel matching,
and toplevel excludes skipping the whole monitor. Additionally verified
manually that config loading via sap.cfg (exclude_paths += [...])
works with the existing exec() mechanism and correctly filters the
node on a live system.

Is this a new problem? What made you submit this PR?
Not new — a structural limitation of the allow-list-only filtering. It
became relevant while curating monitor_paths for an S/4HANA system,
where the CCMS number range monitor is genuinely valuable but the
rolling technical number range ALAUTOUID permanently sits above its
warning threshold and turns the service into noise.