Add automation types and services

[ferglor]

The bulk of this PR is a cut/paste of the v3/types package in chainlink-automation

We're also moving the MercuryCredentials type from core, into the RelayArgs

Aside from that, I've added some new functions to the AutomationProvider that will expose services needed for automation in core

Associated PRs

chainlink: smartcontractkit/chainlink#11631
chainlink-automation: smartcontractkit/chainlink-automation#299

[jmank88]

ReplaceAll is available:

Suggested change

	checkResultStringTemplate = strings.Replace(checkResultStringTemplate, " ", "", -1)
	checkResultStringTemplate = strings.Replace(checkResultStringTemplate, "\t", "", -1)
	checkResultStringTemplate = strings.Replace(checkResultStringTemplate, "\n", "", -1)
	checkResultStringTemplate = strings.ReplaceAll(checkResultStringTemplate, " ", "")
	checkResultStringTemplate = strings.ReplaceAll(checkResultStringTemplate, "\t", "")
	checkResultStringTemplate = strings.ReplaceAll(checkResultStringTemplate, "\n", "")

Although this seems odd. Is the point to keep it in human readable form in source?

[jmank88]

Oh and there is a Replacer:

Suggested change

	checkResultStringTemplate = strings.Replace(checkResultStringTemplate, " ", "", -1)
	checkResultStringTemplate = strings.Replace(checkResultStringTemplate, "\t", "", -1)
	checkResultStringTemplate = strings.Replace(checkResultStringTemplate, "\n", "", -1)
	checkResultStringTemplate = strings.NewReplacer(" ", "", "\t", "", "").Replace(checkResultStringTemplate)

[ferglor]

Yeah so the init implementation is just to collapse the more readable source string into a single line; my understanding here is that using a JSON encoder was deemed to be too expensive at the time, and using a string template was cheaper/faster. I didn't want to modify any of the code lifted out of automation in this PR; I wanted to keep everything as it was written in the automation repo to keep the impacts of these changes to a minimum

[jmank88]

I see a lot of [32]byte hash types. Is that something we will have to relax later on for other chains? like to a slice []byte?

How are these values actually used? The approach taken with accounts is to just use a string, which for EVM happens to be the encoded hex format, but then never try to parse those values - only compare them directly. It would be nice to be able to make a similar kind of simplification here.

[ferglor]

The TxHash is used to build a log identifier for a log event; I think we use the block hash as well and a few other fields maybe? I think we also hex encode this field for a string representation as well!

[infiloop2]

Having these as concrete [32]bytes gives us a lot of safety as these values are sent within observations and outcomes in OCR, and having a tight control on the size reduces surface area for potential security issues + gives us better control over how many upkeeps we can include in an observation/outcome.

We haven't run into chains where this has been an issue yet, but if we generalise this to byte slice then will need to do a proper review of any downstream implications.

[jmank88]

You can use services.Service for this common set.

Suggested change

	Name() string
	Start(_ context.Context) error
	Close() error
	Ready() error
	HealthReport() map[string]error
	services.Service

You might want/need to upgrade anything with Start/Close to services.Service also, since that suggests they have background processes/state that could be monitored.

[jmank88]

Otherwise there is services.StartClose:

type StartClose interface {
	Start(context.Context) error
	Close() error
}

[amirylm]

We can avoid Start() and Close() functions for all interfaces, as they are not really part of the interfaces (at least not the logical interface) and are only called from within the repo with the implementations

[ferglor]

So the list of automation services in core is now a []job.ServiceCtx, and the AutomationProvider exposes the upkeep state store as this interface type, which is why this was implemented