feat: Request chaining & Dependency graphs

[laurentsenta]

We'll have to prepare for test cases where we need to have requests and checks that depend on the result of other requests.

For example:
A test wants to query an endpoint, retrieve the ETAG from the response, then check that subsequent calls to the same endpoint reusing the ETAG value gives a 304 - Not Modified.

We used a minimal approach to implement these test:

- define empty variable "etag"
- call Run(test1), which has a Function Check which updates "etag" with a side effect
- call Run(test2, test3) which reuses "etag".

@galargh investigated a few approaches:

• define a "Future" that requests might fulfill or use (PR).
• have an API to define side-effects (PR).

We used a minimal approach instead (PR), which does the side-effect explicitly, without endorsing it in the API.

That won't scale to more complex test cases, and we should be ready to implement a "better" approach, ideally, that should:

• make dependencies explicit
• be declarative
• be compatible with the rest of the API (templates, decorators used to generate more tests)
• play nice with IDEs and tooling (use variable instead of raw strings, etc).

Using futures values should work: a future might "taint" values and templates where they are used (templating with a future returns a future). At evaluation time, we can do a topological sort to find the order of execution.

Refs:

• https://marc-ed-raffalli.github.io/declarative-e2e-test/#steps