Description
I wanted to bring this proposal forward with the aim to simplify the base client interface, and rather make it easier to extend (later proposals, have some ideas there).
As @lukebakken mentioned here this aims to simplify the basic API, making it minimal in the sense that it simply exposes the AMQP methods and rather provides extensibility points where additional features/logic can be added.
Reasoning: The WaitForConfirms methods are not recommended and streaming confirms is the recommended practice according to the documentation so therefore I don't think it makes sense for them to be provided by the base API, where additional overhead and locking is required to maintain bookkeeping for delivery tags through linked lists and synchronization primitives (CountdownEvent in this case). If the main API provides the required notifications through events or handler interfaces that could easily separate this logic from the main client, making it simpler.
Also, since WaitForConfirms was mostly aimed at being able to wait for batches of messages being confirmed, and since we now have built-in batching (through channels today, or pipelines possibly later), there is really no reason to keep PublishBatch around, since it has been made pretty much redundant. Also, that functionality could also be provided through extensions methods as well rather than be a part of the main client.