feat: dry-run external services

[Neurone]

Problem description

When using the dry-run feature Guardian records Hedera and IPFS operations into the database instead of sending out real transactions or data.

Considering the rest of external services, the Guardian still interact with those services as it would do for a policy in production.

This means I spend money (for example in case of paid external services) or use real data and live services even though I'm currently using the policy in an explicit fictional or development scenario.

Requirements

The goal is to allow optionally using live external sandboxes or test environments for the dry-run mode, or get mocked data. In case none of them is configured, the execution continues as usual: the Guardian calls the external service as in production mode.

Core

• Allow the configuration of specific endpoints and mocked data for each external service to be used when the policy is executed in dry-run mode.
• Allow any user (SR, VVB, normal users, etc.) to override the Guardian instance level configuration for the external service endpoints and mocked data. Those configurations will be used when the user is in dry-run mode instead of the guardian instance ones. In particular:
  • Allow SRs to set endpoints and mocked data to be used for every imported policy when executed in dry-run mode
  • Allow any user (SR, VVB, normal users, etc.) to set their own endpoints and mocked data to be used for all their policies in dry-run mode
  • Allow any user (SR, VVB, normal users, etc.) to set their own endpoints and mocked data to be used for a single polocy in dry-run mode
• Implement precedence logic for endpoints and mocked data to be used during policy execution in dry-run mode, such as the configuration found will be used:
  1. User-defined mocked data at policy level. "Users" here means any user type: SR, VVB, normal, etc.
  2. User-defined dry-run endpoints at policy level. "Users" here means any user type: SR, VVB, normal, etc.
  3. User-defined mocked data at global level. "Users" here means any user type: SR, VVB, normal, etc.
  4. User-defined dry-run endpoints at global level. "Users" here means any user type: SR, VVB, normal, etc.
  5. SR-defined mocked data at policy level
  6. SR-defined dry-run endpoints at policy level
  7. Guardian instance mocked data
  8. Guardian instance dry-run endpoints

UI

• Offer a UI to set the above mentioned dry-run endpoints and mocked data globally at user level
• Offer a UI to set the above mentioned dry-run endpoints and mocked data at policy instance level
• Offer a UI to set the above mentioned dry-run endpoints and mocked data at Standard Registry level (all policies imported by that SR will use those configurations)
• Offer a UI to the SR to check the global overriding levels currently configured for its policies (all levels). The SR will be able for example to see if a user overrides the dry-run endpoints and the mocked data at policy or instance level, and what their actual value is.
• Highlight when a policy uses external services and allows setting custom dry-run endpoints or mocked data.
• Highlight when a policy is using custom dry-run endpoints and/or mocked data instead of the Guardian instance level.

API

• Extend the existing APIs to allow users to set the above mentioned endpoints and mocked data.