Add v1helpers.NewTestHttpUpstreamWithHttpbin for testing purposes

[ryanrolds]

Description

In another WIP PR I need to make assertions against the headers that made it upstream. The PR introduces a new upstream generate that creates an go-httpbin backed upstream. I'm breaking the change out to make the original PR smaller and allow for specific discussion of this upstream generator.

I believe this upstream generator is useful because:

• Provides way of inspecting what is seen by the upstream workload
• Allows inspecting headers, methods, status codes, etc...
• It's not starting up an httpbin container, instead it's using a Go test server running in the tests (lightweight)

An example of the httpbin upstream being used can be seen in the WIP PR tests.

Code changes

• Added v1helpers.NewTestHttpUpstreamWithHttpbin(...)

Checklist:

• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [ ] I have added tests that prove my fix is effective or that my feature works

[github-actions[bot]]

Visit the preview URL for this PR (updated for commit 9c862c4):

https://gloo-edge--pr10288-rolds-test-httpbin-u-cqabry0i.web.app

_{(expires Thu, 14 Nov 2024 22:38:54 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 77c2b86e287749579b7ff9cadb81e099042ef677}

[ryanrolds]

/kick

[ryanrolds]

This change will likely land with the other PR. I will close this PR when the other is merged.

This creates multiple ways for developers to construct testupstream servers. How will they know which one is useful for which situation?

It will depend on the context. This is for HTTP, not gRPC (maybe also add a generator for https://github.com/moul/grpcbin), and maybe they need very specific responses in a specific sequence. My expectation, which may be false, is that most engineers working in the K8s ecosystem are familiar with httpbin.

With the existing server, we have found that there are lots of constructors required to create servers with slightly different behaviors. Is there a way we can build a single constructor with better dependency injection, so that future customizations can be more easily added?

Yes, we can make a generator has all of the server start/shutdown and channels bits but lacks routing. It would take a http.Handler and run all requests through that handler. For complex cases engineers will have to build a little state machine (that provides the http.Handler interface) that can be interrogated.