actions: fix cycle when multiple actions are triggered across multiple events

[liamcervante]

This PR fixes a bug in actions that occurs when multiple actions target multiple events. When we were connecting edges in the apply graph, between action invocations, we make sure that actions that are defined "later" in the configuration execute after actions that are defined earlier. But, this only matters if the actions are defined within the same "triggering event", an action that is triggered "after_create" should always happen after a "before_create" action. If an "after_create" action was defined before a "before_create" action, we'd get a cycle as the logic would draw an edge between those actions.

This PR updates the logic for working out those edges, and only draws edges between nodes within the same trigger. Nodes in different triggers are already connecting to the actual resource in the correct ordering so we can simply exclude actions in different triggers.

In addition, this fixes a small n^2 operation against the number of action invocations in the configuration, instead we map the actions to the triggering resource and we don't need to iterate through all the action invocations to find the ones that are mapped against the same resource.

Target Release

1.14.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[DanielMSchmidt]

Don't we need a test case in the apply graph as well?

[liamcervante]

I can add one, but it's covered by the part of the plan graph that builds the apply graph before it returns. Let me know, I can add one if you think it's important but the specific part of the code raising the cycle is being covered just with a test during planning 👍