Acceptance tests assume endpoint addresses

[timbussmann]

We have quite a few acceptance tests using AddMapping to add a message endpoint mapping to allow the test to route messages between endpoints in the test.

The message endpoint mappings use the configured value as an address, not as a logical endpoint name. This means that all transport running these tests actually need to follow the assumed convention.
When using the new routing API, using logical endpoint names, instead, it will try to translate the logical name into a transport address using the transport infrastructure.

I think we should get rid of all AddMapping usages in the tests. This aligns well with the potential removal of MessageEndpointMappings anyway.

The problem with that goal is that routing configuration using the routing API is a bit ugly since it's a sub-API of the transport configuration which isn't available in the acceptance tests. But we already provide a workaround for the acceptance tests to get access to the message driven pub/sub API without needing the transport config directly (MessageDrivenPubSubRouting), the same approach could be used to make the routing API available in acceptance tests.

e.g.

            EndpointSetup<DefaultServer>(builder =>
            {
                // the CommandRouting extensions shortcuts UseTransport<>().Routing()...
                builder.CommandRouting().RouteToEndpoint(typeof(MyEvent), typeof(Publisher));
            });

maybe there's a better solution for this approach?