CRE Don2Don accept OCR attestation of a response

[dhaidashenko]

Ticket: https://smartcontract-it.atlassian.net/browse/PLEX-2611
Depends on:

• Allow capability DONs to include OCR attestation of the responses chainlink-common#1907

[github-actions]

CORA - Pending Reviewers

Codeowners Entry	Overall	Num Files	Owners
/core/capabilities/	⏳	7	@smartcontractkit/keystone, @smartcontractkit/capabilities-team
go.mod	⏳	6	@smartcontractkit/core, @smartcontractkit/foundations
go.sum	⏳	6	@smartcontractkit/core, @smartcontractkit/foundations
integration-tests/go.mod	⏳	1	@smartcontractkit/core, @smartcontractkit/devex-tooling, @smartcontractkit/foundations
integration-tests/go.sum	⏳	1	@smartcontractkit/core, @smartcontractkit/devex-tooling, @smartcontractkit/foundations

Legend: ✅ Approved | ❌ Changes Requested | 💬 Commented | 🚫 Dismissed | ⏳ Pending | ❓ Unknown

For more details, see the full review summary.

[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

[cl-sonarqube-production]

Quality Gate passed

Issues
4 New issues
1 Fixed issue
0 Accepted issues

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

See analysis details on SonarQube

[patrickhuie19]

do all consumers of ocr signed reports have to do this validation? maybe there's a shared lib in chainlink-common or libocr we can use?

[dhaidashenko]

We have two consumers of OCR reports:

1. On-chain contracts (code reuse is not possible)
2. Liboccr. Code reuse is also not possible as signatures are streamed from other nodes and in this case, we have all of them in one place.

Extracting this for loop into a dedicated function in common does not seem like a good idea at this stage, since it's not shared with any other caller right now.
And even if someone in the future needs to use something similar, I do not see any issues with duplicating the code or extracting it at that stage, as the logic is trivial and will always converge to the same code, except for some minor differences.

[patrickhuie19]

could benefit from a library on the client side that crafts resp.Metadata.Metering[0] in the way we expect here

[dhaidashenko]

I've consolidated logic for interacting with metering details in the client_request.
If you meant a method to craft resp.Metadata.Metering[0] on the capabilities side, I agree that it's beneficial. However, it's out of scope for this PR.