proxy_serve_stale: Test updates

[bneradt]

This updates the proxy_serve_stale test to run more quickly (about 15
seconds instead of about 2 minutes). While doing so, the test is also
converted to use Proxy Verifier.

---

Other than adjusting the timing this is not a functional change. The same transactions are performed to exercise serving the stale entries.

[bneradt]

@serrislew: can you please review this?

[serrislew]

Looks good to me. Is this the standard of how autests should be created now?

[bneradt]

Looks good to me.

Thank you for the review, @serrislew.

Is this the standard of how autests should be created now?

Standard is a strong word. In case it's helpful to share, here are a couple of my observations with the AuTests:

Test Class Organization

I noticed when reviewing @masaori335's PRs that when he adds AuTests he structures them around a test class with helper methods that define each component of the test (setup_traffic_server, setup_server, run_the_cases, etc.). I find this a very helpful way to organize the test for readability. So I picked this up from him and generally follow his example.

Proxy Verifier

Proxy Verifier has some advantages over curl:

• It has an expressive traffic verification mechanism that is inlined with the traffic description (the replay files). This is a more purpose built and explicit method for verifying the traffic than using gold files against curl output. Gold files are fine in many contexts (for verifying log output, for instance), but the gold matching mechanism is a pretty generic way to verify output in comparison to being able to verify the characteristics of a header with various directives (equal, contains, present, case sensitive or insensitive, etc), or a response code, or the HTTP body, or any combination of the three.
• Along these lines, Proxy Verifier test failures in AuTest will print out the specific Verifier error message indicating what went wrong. For example, an error message might say, [ERROR]: HTTP/1 Status Violation: expected 200 got 201, key: push. This is usually a more precise and readable AuTest failure than a gold file diff output.
• Helpful for this test, it also has delay mechanisms that can be expressed in the replay file.
• With curl, if a server is needed, the client (curl) and the server (usually microserver) have to be configured independently of each other. With Proxy Verifier, the same replay file configures both the client and the server.
• When using multiple curl calls in AuTest, they are often separated by independent TestRun objects. (That wasn't the case with this test, but often separate runs are helpful for verifying each curl result independently.) AuTest has some overhead when processing the processes of each test run which slows down the test. When all the transactions are specified in a single TestRun invocation of Proxy Verifier client and server, this can greatly speed up the test.

For these reasons, I prefer using Proxy Verifier over curl in many cases. But I'm biased since I maintain the Proxy Verifier project (@SolidWallOfCode wrote the initial version of Proxy Verifier, I now maintain it). That said, I still do sometimes use curl when all that is needed is a simple request to exercise ATS when no server is needed. In those cases, creating a replay file is verbose in comparison to a simple curl command.

---

That guides me when I work with AuTests. But I won't block PRs that don't follow these practices.

[zwoop]

Cherry-picked to v9.2.x