MINIFICPP-2775 Allow manifest generation for comparison between releases

[martinzink]

Dont be alarmed the 11.6k line change is mostly a test reference json. The actual changes are minimal

---

Since there are a bunch of refactors due to the stable API and how we load/register processors it would be benefitial to make sure we dont break the manifest unintentinally.

I've added a CI action that compares the manifest to a reference manifest.

---

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced
  in the commit message?

• Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically main)?

• Is your initial contribution a single, squashed commit?

For code changes:

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE file?
• If applicable, have you updated the NOTICE file?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.

[Copilot]

Pull request overview

This PR adds a deterministic “component manifest” generation path and a CI check to diff the generated manifest against a stored reference, helping detect unintended manifest changes across releases/refactors.

Changes:

• Add a --manifest CLI option to output a serialized component manifest (intended for release-to-release comparison).
• Make manifest output stable by sorting component/class-description contents before serialization.
• Add a CI step to diff the manifest output against a reference JSON file; update argparse dependency and GitHub Actions cache-cleanup workflow/script paths.

Reviewed changes

Copilot reviewed 6 out of 10 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
minifi_main/MiNiFiMain.cpp	Adds --manifest flag, disables logging for manifest generation, and routes to manifest generation code path.
minifi_main/AgentDocs.h	Exposes AgentDocs::generateManifest() API.
minifi_main/AgentDocs.cpp	Implements manifest generation and adds sorting to stabilize output ordering.
cmake/ArgParse.cmake	Updates bundled argparse version (needed for new CLI flag handling).
.github/workflows/clear-actions-cache.yml	Updates workflow to use the relocated .github/github_scripts paths.
.github/workflows/ci.yml	Adds a “Check manifest” step that diffs --manifest output against a reference file.
.github/github_scripts/requirements.txt	Adds Python dependency for the cache-cleanup script.
.github/github_scripts/github_actions_cache_cleanup.py	New GitHub Actions cache cleanup script.
.github/github_scripts/github_actions_cache_cleanup_tests.py	Adds unit tests for the cache cleanup logic.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[szaszm]

Would it be beneficial to compare the entire agent manifest, instead of just the component manifest? Why did you decide against it?

[martinzink]

Would it be beneficial to compare the entire agent manifest, instead of just the component manifest? Why did you decide against it?

Good point, I've tried it, but it contains a lot of unique identifiers and timestamps so it would be not straight forward to reuse AgentManifest, the only upside would be that it would contain schedulingDefaults, and supportedOperations.
But maybe we could deal with these in a separate PR