Response Negotiator

[khellang]

OK, so this is most of the change I've been wanting to get in for a while (in #1213). It's basically ripping out the conneg parts from the DefaultRouteInvoker and putting them in a separate service IResponseNegotiator with it's default implementation DefaultResponseNegotiator.

I'd refactor (move) the tests as well, but it seems there's no unit tests for the conneg parts and 92% of the new response negotiator is covered by functional tests (the rest is trace calls).

The next step (for a future PR) would be to use this service to do conneg in other pipelines 😄

[horsdal]

This method is very long. I'd do some extract methods. A few suggestions for where below.

[khellang]

Sure, by all means. Some of the methods could be refactored. They're just a clean rip-out from the existing conneg stuff from DefaultRouteInvoker 😉 @thecodejunkie, @grumpydev what do you say?

[khellang]

Alright @horsdal, what do you think now? I struggled a bit to grasp what the existing methods tried to accomplish, so I factored them a bit differently and added XML comments so anyone should be able to understand the basics of what's going on. Here's a map of the method calls:

I also took the liberty of replacing the IEnumerable<Tuple<string, IEnumerable<Tuple<IResponseProcessor, ProcessorMatch>>>> with IEnumerable<CompatibleHeader> since it reads a bit better and creates less noise when being passed around 😉

[horsdal]

@khellang Much nicer factoring! The methods make a whole lot more sense to me now.
Also agree on encapsulating Tuple<string, IEnumerable<Tuple<IResponseProcessor, ProcessorMatch>>> in CompatibleHeader.

[grumpydev]

I actually find Tuple<string, IEnumerable<Tuple<IResponseProcessor, ProcessorMatch>>> more readable 😉

[realmerx]

+1