Add a 'trustEnclaves' setting to confidential relay for testing

[vreff]

Adds a trustEnclaves boolean to the confidential relay toml config. This enables E2E testing to use fake enclaves rather than real ones.

[github-actions]

I see you updated files related to core. Please run make gocs in the root directory to add a changeset as well as in the text include at least one of the following tags:

• #added For any new functionality added.
• #breaking_change For any functionality that requires manual action for the node to boot.
• #bugfix For bug fixes.
• #changed For any change to the existing functionality.
• #db_update For any feature that introduces updates to database schema.
• #deprecation_notice For any upcoming deprecation functionality.
• #internal For changesets that need to be excluded from the final changelog.
• #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
• #removed For any functionality/config that is removed.
• #updated For any functionality that is updated.
• #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

[github-actions]

✅ No conflicts with other open PRs targeting develop

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[github-actions]

CORA - Analysis Skipped

Reason: The number of code owners (4) is less than the minimum required (5) and/or the number of CODEOWNERS entries with changed files (5) is less than the minimum required (2).

[cl-sonarqube-production]

Quality Gate passed

Issues
1 New issue
7 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[nadahalli]

I have always strived to not add "test parameters" to signatures, but I guess in this case, this is the best way of doing it.

[vreff]

I have always strived to not add "test parameters" to signatures, but I guess in this case, this is the best way of doing it.

Yeah, not sure there's a better solution here. LMK if you think of one.

[cfal]

I have always strived to not add "test parameters" to signatures, but I guess in this case, this is the best way of doing it.

Yeah, not sure there's a better solution here. LMK if you think of one.

i wonder if it makes sense to add some NitroValidator interface which we can store in Handler, where the real impl calls nitro.ValidateAttestation/nitro.ValidateAttestationWithRoots, and a relaxed version used for tests can do something else. then it would be handled at instantiation. perhaps not much cleaner?

[vreff]

i wonder if it makes sense to add some NitroValidator interface which we can store in Handler, where the real impl calls nitro.ValidateAttestation/nitro.ValidateAttestationWithRoots, and a relaxed version used for tests can do something else. then it would be handled at instantiation. perhaps not much cleaner?

Right. It would only be spawned by a toml configuration still, but maybe I can re-arrange this to be a handler that gets passed in rather than a bool.