Public api cleanup round 2

[bording]

Proposed Changes

@lukebakken Here's my second pass at cleaning up the public API surface. With this PR, I think most/all of the low-hanging fruit is gone.

I do still think there's more of the API surface that should be looked at, but cleaning it up further will require some effort to untangle things, for example where there are public and internal concerns intermingled. There are certainly more interfaces than are likely needed. Seems like some actual design discussions will be needed to make more improvements here.

One thing specifically that's still bothering me is ConsumerWorkService. It's now the only public class in the RabbitMQ.Client.Impl namespace. Its async equivalent, AsyncConsumerWorkService, is already internal.

I played around with making it internal as well, but the way things are currently structured, the public IConnection has a ConsumerWorkService property that is there solely to provide access to the work service to other implementation classes.

Perhaps a separate PR just to make it clear what sort of changes would be required to fix it?

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask on the
mailing list. We're here to help! This is simply a reminder of what we are
going to look for before merging your code.

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• All tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in related repositories

[stebet]

There is also some code that is not used anywhere except in test, that after being internalized can probably be deleted right? Examples are SetQueue and SharedQueue for example.

[bording]

There is also some code that is not used anywhere except in test, that after being internalized can probably be deleted right? Examples are SetQueue and SharedQueue for example.

Yes, that is likely true, but not what I was focused on for these PRs. Now that all that stuff is internal, it can be cleaned up later on without requiring a new major version!

[lukebakken]

Perhaps a separate PR just to make it clear what sort of changes would be required to fix it?

Great idea! Thanks for all your work.

[bording]

@lukebakken I rebased this to resolve conflicts, so it should be ready to go again.

It appears that the Travis build completed properly but didn't report progress back to the PR.

[lukebakken]

Thanks @bording !