Add arg_minimal_value variable to grub2_bootloader_argument template

[macko1]

Description:

• Add an operation parameter to the grub2_bootloader_argument
  template so rules can use numeric comparisons (currently only
  "greater than or equal" is supported)
• Update grub2_audit_backlog_limit_argument rule to use the
  new operation parameter.
• Update test scenarios to be more modular by passing custom testing values with template.py instead of embedding the hardcoded values in the test itself.
• Added tests for "greater than or equal" scenarios.
• Document the new parameter in template_reference.md.

Rationale:

• audit_backlog_limit=8192 was failing on systems with a higher
  value like 16384, because the OVAL check did an exact string match
  instead of a >= comparison.

• Fixes xccdf_org.ssgproject.content_rule_audit_backlog_limit resets backlog limit even if set to valid value #13923

Review Hints:

• Review commits in order: template.py first (preprocessing), then
  oval.template + tests (the OVAL plumbing), then rule.yml + docs.
• Build and test with:

./build_product rhel9 --datastream-only

• Test with automatus.py - this needs to be run in a VM, not a container.
  Using multiple parallel VMs is recommended (--slice automatus argument).

./automatus.py rule --libvirt qemu:///session <vm> --datastream ../build/ssg-rhel9-ds.xml grub2_audit_backlog_limit_argument

• The oval.template has extensive inline comments explaining the
  numeric branching — the header TOC (lines 1–72) is a good
  starting point.
• The RHEL8 entries_numeric test+object (section 4a) is the
  trickiest part — it exists because the wide-capture object must
  stay for $kernelopts detection.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[github-actions]

This datastream diff is auto generated by the check Compare DS/Generate Diff

Click here to see the full diff

OVAL for rule 'xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument' differs.
--- oval:ssg-grub2_audit_backlog_limit_argument:def:1
+++ oval:ssg-grub2_audit_backlog_limit_argument:def:1
@@ -1,6 +1,6 @@
 criteria OR
 criteria AND
-criterion oval:ssg-test_grub2_audit_backlog_limit_entries_expanded_or_referenced:tst:1
+criterion oval:ssg-test_grub2_audit_backlog_limit_entries_numeric:tst:1
 criteria OR
 criterion oval:ssg-test_grub2_audit_backlog_limit_at_least_one_entry_referenced:tst:1
 criteria OR

[github-actions]

Change in Ansible shell module found.

Please consider using more suitable Ansible module than shell if possible.

[vojtapolasek]

Hello @macko1 and thank you.
I have two remarks. First is technical, could you please split the PR into multiple commits? For example, one for documentation, one modifying tests... it makes reviewing easier.
Then I have a remark regarding the main purpose of the PR. As I understand it, your PR makes it possible to define the Grub2 value in three ways:

• arg_value - checks equality of the value against hardcoded value
• arg_variable - checks equality with a value represented by an XCCDF variable
• newly defined arg_minimal_value - checks if the value is greater or equal to a hardcoded value
  If I understand it correctly, then I think this is not an optimal implementation.
  Because what if in the future you would like to check if a value is greater or equal to something defined with XCCDF variable? It would require another round of reimplementation.
  I think it would be better to add a different parameter, which would signify the operation between the checked value and the hardcoded / variable provided value. In this way, we could check for equality, greater than, lesser than... whatever is supported.
  I had only a quick glance into templates, but it seems we already support this for example in the accounts_password template or pam_options template. Do you think this concept could be used in this case as well?

[macko1]

@vojtapolasek you were right, thanks for pointing this out. I've re-implemented the check, and made it extensible - "greater than or equal" can be extended with more OVAL operations in the future, when needed.

I have divided the changes into several commits, as you have asked, I hope this will make it more readable.

PR description updated.

Thanks for a review!