test: introduce flag for trace input to e2e framework

[p-offtermatt]

Description

Closes: Part of #1265

• added a new flag --test-file filename::testrunner
• These changes are made so that the steps and the runner are separated. This is more future proof, and for test-file, specifying the test runner separately is necessary. The test runner for the pre-defined test cases is optional, and if not specified it just uses the first compatible one. I think this will be a useful pattern to have in the future, since we are planning to allow running the same tests in different contexts, e.g. with various configurations

I also refactored the TestRun struct to be called TestConfig - this seems much closer to what it actually represents.
The old name was confusing, because the Steps and the TestRun are different things, adn TestRun really sounds like
it contains the steps, which was not the case.

To review this...

• check that actions*.go, config.go and state.go only contains the refactor of changing TestRun to TestConfig
• check that all references to TestRun are changed to TestConfig
• check the meat of the changes: the behaviour of the new flag in main.go

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• Included the correct type prefix in the PR title
• Targeted the correct branch (see PR Targeting)
• Provided a link to the relevant issue or specification
• Reviewed "Files changed" and left comments if necessary
• Confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• Confirmed the correct type prefix in the PR title
• Confirmed all author checklist items have been addressed
• Confirmed that this PR does not change production code

[MSalopek]

Great work!

I have no issues with the current work. I'll avoid nitpicking.

One idea that comes to mind as a possible refactor is de-coupling configurations from test actions.
Instead of binding actions to config, each action can take a config as argument. However, that does not have any immediate impact and is quite a large refactor.

[p-offtermatt]

Great work!

I have no issues with the current work. I'll avoid nitpicking.

One idea that comes to mind as a possible refactor is de-coupling configurations from test actions. Instead of binding actions to config, each action can take a config as argument. However, that does not have any immediate impact and is quite a large refactor.

Thanks. I agree this is a possible refactor. I think that's something we may want to keep in mind, but I don't think it's important enough to prioritize. I added an issue
that we can keep around to have a bit of context #1325

[shaspitz]

The new naming is great, thanks! W.r.t above comment I don't see any immediate impact of making action funcs accept TestConfig as an argument, instead of making the action funcs methods of TestConfig.

From my understanding, golang does not offer any meaningful differences between funcs accepting an obj, and methods defined on an obj, unless interfaces are involved.

[p-offtermatt]

The new naming is great, thanks! W.r.t above comment I don't see any immediate impact of making action funcs accept TestConfig as an argument, instead of making the action funcs methods of TestConfig.

From my understanding, golang does not offer any meaningful differences between funcs accepting an obj, and methods defined on an obj, unless interfaces are involved.

This is also my understanding. I think it looks slightly off that actions are methods of the TestConfig, so I think the refactor would have some minimal value, but yes functionally I think this changes nothing.