feat: multichain ocr3 contract transmitter

[makramkd]

The Lock/Unlock plugin will need an OCR3 transmitter that can transmit to many chains based upon the info being provided in the ReportWithInfo struct.

In order to achieve this, we need to implement two things:

• A multi-chain contract config tracker implementation (OCR3 interface: https://github.com/smartcontractkit/libocr/blob/c5102a9c0fb776e79cc72d313a61543dc5d48ee2/offchainreporting2plus/types/types.go#L337) that coalesces all the different transmitter addresses on the many different chains into a single ocrtypes.Account object.
• A multi-chain contract transmitter implementation (OCR3 interface: https://github.com/smartcontractkit/libocr/blob/c5102a9c0fb776e79cc72d313a61543dc5d48ee2/offchainreporting2plus/types/types.go#L303) whose FromAccount() returns one big Account value formatted the same way as the one returned by the ContractConfigTracker in the previous bullet.

With this in mind, this PR:

• Creates a regular OCR3 contract transmitter that is based off of the OCR2 contract transmitter
• Creates a multi-chain contract config tracker which tracks config changes on a single ("master") chain and combines config updates from all chains into a single config using a parametrizable CombinerFn
  • A CombinerFn is implemented which groups all transmitters for a single signer into a single types.Account object. See TransmitterCombiner in the PR changes.
• Adds the OCR3Abstract, OCR3Base and NoOpOCR3 contracts to generate gethwrappers and use the associated ABI and ConfigSet event objects in the config tracker.
  • In theory, all OCR3 contracts should inherit OCR3Base and have the same exact ConfigSet event signature.
• Creates a multichain OCR3 contract transmitter that wraps many different OCR3 transmitters and implements FromAccount matching the TransmitterCombiner CombinerFn implementation.
• In order to test the above, adds the base OCR3 contracts to the shared subdirectory of the contracts directory and adds a NoOpOCR3.sol implementation that does nothing in _report just to test the end-to-end of the transmitter.

[github-actions]

I see that you haven't updated any CHANGELOG files. Would it make sense to do so?

[dimkouv]

will never be Unregistered?

[makramkd]

Do unregisters need to happen?

[dimkouv]

cc @reductionista

[cl-sonarqube-production]

SonarQube Quality Gate

Reliability Rating on New Code (is worse than A)

See analysis details on SonarQube

Fix issues before they fail your Quality Gate with SonarLint in your IDE.

[makramkd]

Moving to CCIP: smartcontractkit/ccip#414