Refactor IMessageDispatcher into Middleware

[gkinsman]

This PR partially resolves #875 by moving much of the post-processing code from the MessageDispatcher to separate middlewares.

The default middleware chain for all handlers is now:

"MiddlewareChain": [
  "MessageContextAccessorMiddleware",
  "ErrorHandlerMiddleware",
  "LoggingMiddleware",
  "StopwatchMiddleware",
  "SqsPostProcessorMiddleware",
  "HandlerInvocationMiddleware`1"
]

It is also now possible to modify the middleware configuration from the subscription builders directly, where before you had to go via the SqsReadConfiguration.

Before:

(TopicSubscriptionBuilder<SimpleMessage> c) => 
  c.WithReadConfiguration(rc =>
      rc.WithMiddlewareConfiguration(m =>
        m.UseExactlyOnce<SimpleMessage>("simple-message-lock")))))

After:

(TopicSubscriptionBuilder<SimpleMessage> c) => 
    c.WithMiddlewareConfiguration(m =>
        m.UseExactlyOnce<SimpleMessage>("lock-simple-message")
         .UseDefaults<SimpleMessage>(handler.GetType()))))

The resulting middleware chain:

        "MiddlewareChain": [
          "ExactlyOnceMiddleware`1",
          "MessageContextAccessorMiddleware",
          "ErrorHandlerMiddleware",
          "LoggingMiddleware",
          "StopwatchMiddleware",
          "SqsPostProcessorMiddleware",
          "HandlerInvocationMiddleware`1"
        ]

The UseDefaults method will add all of the above middlewares as a shortcut for having to add them all manually. Previously it wasn't possible to have a no-op pipeline as the HandlerInvocationMiddleware was always added, but now you can by not calling this.

A bit of debt

The need to include the handler type is to maintain the IMessageMonitor.HandlerExecutionTime(_handlerType, context.MessageType, watch.Elapsed) contract. Possibly this call could be moved to the handler invocation middleware where we have the handler type (so that we don't need to resolve the handler in each middleware).

DI Wireup

There has also been a change to how we resolve services from configuration (using ServicesBuilder) vs the provided IServiceResolver. Previously both the IServiceResolver and the ServicesBuilder were checked to see if the user has overridden various services such as IMessageMonitor via config instead of adding it to the container. IMessageMonitor is used all over the place, so this check had to be done in each location (it wasn't, which was causing bugs).

There is now an IServiceResolver over the ServicesBuilder (ServiceBuilderServiceResolver) that enables resolution from anywhere without needing to care where the component was registered. A CompoundServiceResolver provides a single service resolver for both the service builder resolver, and the user provided resolver (or the DefaultServiceResolver if none supplied).

This is particularly useful for middlewares, as previously we had to know about the ServicesBuilder in order to find the correct IMessageMonitor, for example. We can now wholly rely on a single IServicesResolver.

I'm keen for feedback on this design - it's a little ugly, but IMO superior to infecting the rest of the codebase with knowledge of the services builder.

TODO:

• Add XML docs to new public members
• Cleanup any dead code/things hanging around
• Add some more tests for middleware building

[codecov]

Codecov Report

Merging #932 (c9ba1d4) into main (f5250dd) will decrease coverage by 0.02%.
The diff coverage is 92.19%.

@@            Coverage Diff             @@
##             main     #932      +/-   ##
==========================================
- Coverage   84.39%   84.37%   -0.03%     
==========================================
  Files         120      131      +11     
  Lines        3120     3199      +79     
==========================================
+ Hits         2633     2699      +66     
- Misses        487      500      +13     

Flag	Coverage Δ
linux	84.12% <92.19%> (-0.15%)	⬇️
macos	52.73% <64.72%> (-0.41%)	⬇️
windows	53.11% <64.72%> (+0.15%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...c/JustSaying/Fluent/SqsReadConfigurationBuilder.cs	76.92% <ø> (-6.42%)	⬇️
...ing/Messaging/MessageHandling/MessageAttributes.cs	100.00% <ø> (ø)
...ging/MessageSerialization/MessageWithAttributes.cs	100.00% <ø> (ø)
...aging/MessageSerialization/NewtonsoftSerializer.cs	100.00% <ø> (ø)
...g/MessageSerialization/SystemTextJsonSerializer.cs	100.00% <ø> (ø)
...ng/Middleware/ExactlyOnce/ExactlyOnceMiddleware.cs	77.77% <ø> (-14.82%)	⬇️
...ware/Metrics/MetricsMiddlewareBuilderExtensions.cs	100.00% <ø> (ø)
...Saying/Fluent/QueueAddressSubscriptionBuilder`1.cs	83.33% <50.00%> (-5.24%)	⬇️
...rc/JustSaying/Fluent/QueueSubscriptionBuilder`1.cs	88.33% <50.00%> (-3.34%)	⬇️
src/JustSaying/Fluent/QueueAddressQueue.cs	80.95% <60.00%> (-7.94%)	⬇️
... and 55 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f5250dd...c9ba1d4. Read the comment docs.

[gkinsman]

We can't just resolve the ErrorHandlerMiddleware from the resolver, because if the IMessageMonitor was added via the ServicesBuilder, then resolving the middleware from the resolver will bypass the SB and resolve from the container, which is a no-op by default.

The downside is that middlewares that do this are instance-per-queue instead of shared.

[gkinsman]

This Client property is private now as we no longer expose the IAmazonSqs, so I've removed this command as I don't think its used very much. We have other ways of handling retries.

[martincostello]

This looks good.

I wonder if with the extra CancellationToken usages if anywhere needs changing to more gracefully needs to handle if it fires and causes a cancellation mid operation? (Say between two API calls related to a single message batch, like a receive and then a delete)

[martincostello]

A few comments here and there. Most of it us just me being nit-picky about /// docs and null checks on the public members.