This PR aligns the FIPS 140-3 test plan, generated requirements, and e2e operator test coverage.

Main changes:

• Add the FIPS software test plan under tests/requirements/fips_test_plan.md.
• Restructure and consolidate FIPS requirements in tests/requirements/fips.md.
• Regenerate/update tests/requirements/fips.py from the updated requirement definitions.
• Update FIPS e2e scenarios in test_operator.py to reference the corrected/consolidated requirements.
• Refine FIPS helper steps in steps_fips.py to better match what is actually testable.
• Update ACVP-related requirements/tests for the metrics-exporter wrapper behavior and expected algorithm coverage.

Details

This PR makes the three layers consistent:

1. Test plan

   • Adds the FIPS test plan as an explicit tracked artifact.
   • Documents the intended FIPS coverage and known scope boundaries.

2. Requirements

   • Consolidates duplicate or overly-specific requirements into broader testable requirements.
   • Clarifies FIPS enforcement behavior such as TLS verification coercion, TLS 1.3 minVersion coercion, IPC secure mode, image policy handling, and operator-managed TLS client scope.
   • Adds/updates connection requirements for operator/exporter communication with Kubernetes API, ClickHouse, and Keeper-related paths.

3. Tests

   • Updates scenario requirement links to match the revised requirement structure.
   • Improves TLS checks around real endpoints:
     • Kubernetes API :443
     • ClickHouse HTTPS :8443
   • Verifies TLS 1.3 negotiation with approved AES-GCM cipher suites where applicable.
   • Avoids pretending the operator performs runtime TLS client sessions to Keeper when it normally does not.
   • Keeps checks focused on observable behavior instead of synthetic assumptions that do not represent the real operator data path.

4. FIX

• fixed test_010035_2 manifest and assertion
• fail proofed test_010023 by adding wait for pod deployment

Important items to consider before making a Pull Request

Please check items PR complies to:

• All commits in the PR are squashed. More info
• The PR is made into dedicated next-release branch, not into master branch¹. More info
• The PR is signed. More info

--

¹ If you feel your PR does not affect any Go-code or any testable functionality (for example, PR contains docs only or supplementary materials), PR can be made into master branch, but it has to be confirmed by project's maintainer.