rm_templates: T8609: fix slow parse() from group-quantifier patterns (#470)

* rm_templates: T8609: fix slow parse() from group-quantifier patterns

Running an Ansible playbook that manages BGP route-maps on my VyOS 1.4
edge routers, the vyos.vyos.vyos_route_maps task (state=gathered or
state=merged) takes ~50 seconds per host, sometimes 100s+, against
devices with only a handful of route-maps configured.  The persistent
connection times out before the module finishes and the failure
surfaces as a misleading "socket path does not exist".

Three related quantifier shapes in nine rm_templates files cause O(2^n)
regex backtracking on inputs that share a parser's prefix but don't
match overall.  parse() time on a representative 12-line route-map
config drops from ~50s to <1ms post-fix.

* Trailing form (188 sites): `(?P<X>\S+)\n  *$"""` -> `(?P<X>\S+)\s*$"""`.
  Under re.VERBOSE the literal newline+indent between `\S+` and `*$`
  is stripped at compile time, so the source compiled to `(\S+)*$`
  with the `*` quantifying the named group.

* Mid-pattern `(group containing \S+)*` (22 sites in snmp_server.py
  with a couple in bgp_global*.py): e.g.
  `(?P<protocol>protocol\s\S+)*` -> `(?P<protocol>protocol\s\S+)?`.
  Different position from the trailing form, but the same shape
  underneath (a group whose content includes \S+, quantified with
  `*`), so the same O(2^n) backtracking on prefix-sharing inputs.

* Mid-pattern `(literal-only group)*` (14 sites in snmp_server.py,
  bgp_address_family*.py, bgp_global*.py): e.g.
  `(?P<as_set>as-set)*` -> `(?P<as_set>as-set)?`.  No \S+ inside the
  quantified group, so the backtracking exposure is much smaller.
  On the inputs these patterns actually receive (no device line
  carries duplicate flags) `*` and `?` accept identical input sets,
  so changing to `?` is behavior-preserving.

The first draft of this fix made set_comm_list_delete's
`(?P<delete>\S+)` group required.  The parser's setval emits `set
comm-list delete` with no token after `delete`, so the parser stopped
matching its own output (no existing fixture covered this case, which
is why the regression initially shipped).  CodeRabbit caught it
during review.  Replaced `delete(?P<delete>\S+)\s*$` with
`\s(?P<delete>delete)\s*$` so the named group captures the literal
word `delete`; the result template `{{True if delete is defined}}`
continues to evaluate True.

Affects: route_maps[/_14], bgp_global[/_14], bgp_address_family[/_14],
snmp_server, ospf_interfaces[/_14].

Adds tests/unit/modules/network/vyos/test_rm_templates_perf.py with
a 1-second budget against fixture inputs that have realistic-length
identifiers, plus a round-trip test asserting set_comm_list_delete
matches its own setval-generated line, plus a Bgp_address_familyTemplate14
budget test for symmetry with the other "hot" template families.

* Fix regex backtracking issues in parse() method

Fix slow parse() to prevent regex backtracking on prefix-sharing inputs across multiple files. Add unit test for the bugfixes.

* Refactor bug fixes for regex backtracking improvements

Updated bug fixes to include details on regex backtracking issues in multiple files.

* Fix typo in bugfixes section of changelog

* Update bugfixes for regex backtracking issues

* rm_templates: T8609: route_maps.py: fix remaining trailing `*$` patterns

Five sites in route_maps.py still had the `(?P<name>...)\n  *$` shape that collapses to `(?P<name>...)*$` under `re.VERBOSE`, parsers `sequence`, `on_match_next`, `set_atomic_aggregate`, `set_extcommunity_bandwidth_non_transitive`, and `match_community_exact_match`.  Collapsed each to `\s*$` on the same line as the named group, matching the rest of the PR.

* rm_templates: T8609: route_maps.py: split overlong getval to satisfy E501

Line 517 was 161 chars (`set_extcommunity_bandwidth_non_transitive` parser) and tripped pycodestyle's E501 sanity test in CI.  Split the regex source across two lines at the `\d+)` boundary; under `re.VERBOSE` the literal newline and indent between regex tokens are stripped at compile time, so the engine sees the same pattern.  `\s*$` stays on the same line as the closing capture group, so the group-quantifier shape this PR fixes elsewhere isn't reintroduced.

---------

Co-authored-by: omnom62 <75066712+omnom62@users.noreply.github.com>

0 files changed, 0 insertions, 0 deletions