Swappable input implementations for eTag generation #130

[toddb]

Based on #130, this implementation is to refactor the code and make a hard coded path now able to be swappable via service injection:

• make the code outlined in the ticket as a strategy—I have not changed this code (eg added more error handling)
• I have named it as 'injector' to try and be similar to other naming conventions (struggling with better naming)
• the service is injected with a default implementation of the original implementation (but like others can be overridden)
• all tests successful run but no new ones were added (following conventions that the other injector service wasn't)

Overall constraints:

• be backwards compatible such that no one needs to do an upgrade
• followed conventions of code formatting (as best as possible)
• added documentation aligned with other documentation to keep it in style and extent

Note on bloat:

• the Injector service wraps the eTag generator so that others don't need to upgrade libraries because of an interface change
• the injector service has a parameters class (ETagContext) to be consistent with other services (eg IStoreKeyGenerator/StoreKeyContext)
• the IETagInjector.RetrieveETag method name on is similarly trying to reflect existing naming conventions (eg IStoreKeyGenerator.GenerateStoreKey)

Again, all of this allows me then have a different eTag generation strategy outside the context of the request.

@KevinDockx I hope that gives enough context to see if this is in the right direction. Obviously, happy to makes changes as suits. Cheers

[KevinDockx]

Hi @toddb , that looks great! Just one small request: would it be possible to add (one or more) test(s) for this (if they make sense to you)? Thanks in advance.

[toddb]

@KevinDockx ha ha, I thought that I had warded that off given the base line that I couldn't find tests on the other "injector". Here's a test that the injector reads the response body and can take either an empty or non-empty stream.

It's not a particularly defensive approach and can be happy to throw more exceptions but as I see it the http context implementation does load up the response body.

Note: most tests die if the default pipeline plumbing doesn't work. I have tested the injector rather than plumbing in the pipeline to "show" that it is going to eTag based on the content.

What is interestingly out of scope are other implementations of the injector that make the design look sensible rather than bloated. Cheers

[KevinDockx]

Writing tests for the other "injector"-services is something that's been on my list for a while - someday I'll get there ;-) Thanks for this!

[toddb]

Thanks for the merge and looking forward to it arriving as a nuget package :-)