HttpTest - make the last fake response in the queue "sticky"

[tmenier]

Currently when you set up an HttpTest with one or more RespondWith(...)s, those fake responses are dequeued and returned to calls made in the SUT until the queue is empty, then any subsequent fake calls return a 200 response with an empty body by default.

#481 introduces the idea of responding to specific requests with specific responses, i.e. httpTest.ForCallsTo(...).RespondWith(...). Effectively there will be multiple response queues, and I believe it will be more common to set up just one fake response per queue. And, I think people might expect that response to be returned for every matching call, not just the first one.

To generalize this will require a breaking change for 3.0. Rather than returning an empty 200 after each queued response has been returned once, the last response in the queue will become "sticky", that is it won't be dequeued and will be considered the default response for all matching calls.

[tmenier]

Along with the behavior change itself, there were a couple other consequences that should be considered breaking:

1. HttpTest.ResponseQueue is no longer exposed as a public property. It was going to change anyway, but to get the "sticky" behavior working it got a larger overhaul and technically isn't even a queue of responses anymore.

2. The lower-level RespondWith overload that takes an HttpContent object now takes a Func<HttpContent>. This is because reusing a response (the sticky behavior) will cause an ObjectDisposedException under most circumstances (thank goodness for tests), and it seems like the most foolproof way to avoid that is to recreate the response each time. So basically the queue holds factories now rather than actual HttpContent objects, which might help explain why I'm not even exposing it.

[tmenier]

Now available to test: https://www.nuget.org/packages/Flurl.Http/3.0.0-pre2

[APIWT]

This may be a controversial opinion, but I don't really like the idea of having a queue at all. If you look at mocking frameworks (like WireMock.Net for example), your mock endpoints are sticky until explicitly removed. You could have a callback that is invoked when the mock setup is matched, and that would be a developers opportunity to add a higher priority mock setup or simply remove the existing setup.

[tmenier]

@APIWT I could be wrong, but I think what you're describing (no "queue" at all) is exactly the use case I'm most trying to address with the "sticky" behavior. I think the most common case of it being desirable is when you have just 1 value you always want to return. (Under the hood it's a queue with single item that never gets removed, but you don't really have to think about it that way.)

As far as the callback, that's an interesting idea, but the direction I went in varying the response depending on the call is detailed in #481. Every set of conditions has its own queue, and I believe the more heavily you're using condition-based fakes, the more likely you're going to have 1-item queues that you would expect to be "sticky".