Upgrade to NServiceBus 10.2.3

[danielmarbach]

This PR upgrades ServiceControl to NServiceBus 10.2.3 and applies the related modernization required for the 10.2 upgrade.

As part of that work, assembly scanning has been removed/disabled where appropriate, and the required explicit attributes have been added for message handlers and sagas so they continue to be discovered correctly without relying on scanning.

Details

The main focus of this PR is the NServiceBus 10.2.3 upgrade and the corresponding cleanup needed to align ServiceControl with the newer NServiceBus behavior:

• Upgrades ServiceControl to NServiceBus 10.2.3.
• Removes reliance on assembly scanning where appropriate.
• Adds explicit handler attributes for message handlers.
• Adds explicit saga attributes for sagas.
• Modernizes endpoint configuration for the NServiceBus 10.2.x model.

Transport tests

The transport tests still require the extension stop logging setup for now because the transports have not yet been moved over to the modern Microsoft.Extensions.Logging integration.

That remaining compatibility layer can be removed once the transports are updated to use the newer logging approach.

Custom checks

As an additional fix, this PR also restores support for custom checks loaded through the transport/plugin context.

Transport-provided custom checks were not being picked up correctly because the primary ServiceControl instance and the transport plugin could end up resolving custom check types from different load contexts. That caused the custom check interface/type checks to fail, so those checks were never registered or executed.

With the changes in this PR, custom checks provided by transports can now be loaded and registered correctly from the plugin context. This means transport-specific checks, including ones that historically did not run, should now work as expected.

[danielmarbach]

I've added Brandon as a reviewer because of the plug-in load context changes. I've also added Mauro and Phil as optional reviewers since they were involved in the original plug-in context work a few years ago.

That said, the reason the custom checks were not being loaded is unrelated to the plug-in load context.

However, the current plug-in load context implementation can introduce type binding mismatches between the service collection and the service provider. Specifically, if a type is loaded first within the transport (as is the case with the custom check in this example) and then registered in the service collection, that type may not be considered identical to the corresponding type loaded by the main application context. This can lead to subtle issues, particularly when resolving collections of services (for example, IEnumerable).

The fact that loading the query providers for the monitoring capability currently works is largely coincidental. In that case, the abstraction lives in ServiceControl and is loaded first, which results in the expected type identities and allows service resolution to succeed.

[danielmarbach]

There are individual commits so I suggest reviewing them one by one so that you can also skip the cleanup commit! Most of the cleanup commits follow a strict pattern and therefore it should be very easy to skim over them and use the get up already viewed feature to hide the files from the changes

[danielmarbach]

@bording for you this commit would be relevant