pkg/settings/cresettings: add PerWorkflow.ChainAllowed

[jmank88]

https://smartcontract-it.atlassian.net/browse/PLEX-2121

This PR adds a limits.GateLimiter to be used with a new cresetting PerWorkflow.ChainAllowed. This setting holds both the typical overridable value, as well as a map by chain selector. The latter allows chains to be made accessible via an override on the org, owner, or workflow ID. The former enabled (dis)allowing by default for a particular org, owner, or workflow.

Supports:

• https://github.com/smartcontractkit/chainlink-deployments/pull/8514
• core/services/workflows/v2: enforce PerWorkflow.ChainAllowed gate chainlink#20548

[github-actions]

✅ API Diff Results - No breaking changes

---

📄 View full apidiff report

[pavel-raykov]

I wonder if we care to name it something like AdditionalChain instead of ChainAllowed since the latter seems to imply that the empty value forbids them all, whereas it is just meant that "secret" chains are not allowed yet.

[jmank88]

Empty does forbid them all. We don't have any pre-existing notion of public or private to build on - we just have the chain selector ID.

We could include a default set of public chains here, but I was concerned that is an implementation detail, and regardless it will evolve over time and different between environments and zones, so it can be stale.

[pavel-raykov]

Sorry, so how one will keep it up to date - will we have a file with all chainIDs somewhere?

[jmank88]

In the deployments repo

[pavel-raykov]

Sorry, so how deployments repo is better than a set of public chains here? Is it because the deployments repo is a "source of truth" and is better maintained? Also, currently where would such list of public chainIDs be here?

[jmank88]

https://github.com/smartcontractkit/chainlink-deployments/pull/8514

[pavel-raykov]

why AllowErr and not just Allow ?

[jmank88]

Aligning with the other limiters. We could support both, but the error has metadata that we to expose

[bolekk]

Why only these two?

[jmank88]

We could include more chains, but it would be assuming implementation details about the deployed system, and it can't serve as the source of truth because we need to be able to roll out new chains without making code changes here. I originally had it empty, but we use these dev/testnets (EVM chain ID 1337 and 2337) in tests, so including them seemed worthwhile.

[bolekk]

Why not make it a separate entry following the capability name like "evm"? Or anything outside "PerWorkflow"

[jmank88]

Well we have chain agnostic selectors rather than per-family chain IDs, and we want this to affect reads and writes. Being under PerWorkflow is what allows us to override and grant access at the workflow level.