test(test-tooling): migrate AIO image to Fabric v2.5.6, add constants

[petermetz]

1. The Fabric v2 image has been migrated to the current LTS release
   which has increased stability and of course adheres to general best
   practices more thoroughly since now we are in sync with the Fabric
   maintainers in terms of LTS.
2. The newer versions of the fabric-samples test-net containers have
   some of the configuration files under different paths and this had to be
   reverse engineered by manually inspecting the containers at runtime and
   searching for the same files in different directories. To make this
   easier in the future for people who are using the AIO image, we've added
   a collection of constants to the test-tooling package that stores the
   paths hardcoded that are exported via verbose variable names that pin these
   to the specific Fabric version they are related to so that in the future
   if these paths change again, we can accommodate the change in a way that
   is not too confusing by exporting more variables with slightly different
   names and values.
3. The image built from the updated Dockerfile_v2 is accessible on GHCR
   as: ghcr.io/hyperledger/cactus-fabric2-all-in-one:2024-03-03--issue-2945-fabric-v2-5-6
   which has the v2.5.6 versioned container images pre-cached (embedded) so that
   network transfer does not need to occur and rate limiting doesn't produce
   CI flakes (DockerHub has rate limits for image downloading that we regularly
   hit when we don't embed the Fabric container images this way...).
4. Why can't we just pull the values for these constants directly from the
   container at runtime?
   4.1. The list of constants and their names/values change based on the
   Fabric version that's being used by the AIO image.
   4.2. The only ones that could be pulled are the ones that belong to the
   first organization because this is the one that the CLI container uses.
   4.3. Configuration files that store the constants' values for the second
   organization are also located in different directories depending on the
   Fabric version being used.
   4.4. The fabric-samples repo have been known to make breaking changes
   to older releases which would then make it even harder to debug if we
   had logic for identifying the constants that suddenly broke (this specific
   incident has happened in the past unfortunately)
   4.5. In short, there is definitely a case for applying the DRY principle
   here, but in this particular case it appears to be not worth it due to
   the increased complexity that the convoluted additional logic would bring.

Related but does not fix #1899

Signed-off-by: Peter Somogyvari [email protected]

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[izuru0]

LGTM

[jagpreetsinghsasan]

LGTM