Make endpoint configuration less verbose

[kbaley]

This issue was transferred from a private repository

EndpointConfiguration instances require a lot of settings, most of which rarely (if ever) deviate from default values.

A new EndpointConfiguration instance is, at the very minimum, like the following:

var config = new EndpointConfiguration("endpoint-name");
var transport = config.UseTransport<SomeTransport>();
transport.ConnectionString("bla-bla");

var persistence = config.UsePersistence<SopmePersistence>();
persistence.ConnectionString("bla-bla");

config.SendFailedMessagesTo("error");

Error queue is a mandatory setting, error should just be the default value (UPDATE: it is now). Error management without auditing enabled provides a poor Platform experience, thus (IMO) auditing should be enabled by default, and the AuditProcessedMessagesTo("audit"); should be set automatically in every new endpoint that is not SendOnly.

Defining transport and persistence has similar issues. UseSomething<T>() is very basic and prevents a good API experience. It's impossible to drive the user in realizing that a connection string, or a topology settings are mandatory. Every downstream should provide wrappers for UseSomething<T>() configuration options, such as for example:

config.UseRabbitMqTransport("connection-string");

is equivalent to:

var transport = config.UseTransport<RabbitMqTransport>();
transport.ConnectionString("connection-string");
transport.UseConventionalRoutingTopology();

In the end we know what a sensible default should be, and users have the option to ignore them and use more granular configuration options if they really want. Imagine if we could provide something like:

var config = new EndpointConfiguration("endpoint-name");
config.UseRabbitMqTransport("connection-string");
config.UseSqlPersistence("connection-string", WithOutbox.Enabled );

or even:

var config = new RabbitMqEndpointConfiguration("endpoint-name", "connection-string");
config.UseSqlPersistence("connection-string", WithOutbox.Enabled );

Note: This issue was created before the recent transport API changes. Some of it might be alleviated now.