add size hint variable for PublishBatch creation

[bollhals]

Proposed Changes

add a new method with a size hint for the creation of the list to hold the commands. This can reduce the allocations due to the storage of the commands by half.

Types of Changes

• 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

• 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

Further Comments

This only adds a new overloaded method to the public IModel interface.

[bollhals]

In the test app of stebet, before:

after

[michaelklishin]

This makes a lot of sense since batches are rarely random in size. However, this PR changes the public API and thus needs an API approval test update

dotnet test -f netcoreapp3.1 projects/Unit --filter "FullyQualifiedName~RabbitMQ.Client.Unit.APIApproval"

[michaelklishin]

I updated APIApproval expectations. Thank you for your ongoing contributions @bollhals! 🥇

[michaelklishin]

Backported to 6.x.

[bording]

@michaelklishin This is a breaking change, so it should not have been backported to the 6.x branch.

When looking at the APIApproval changes, any time you see an interface being modified, that is a breaking change.

These are definitely the kinds of changes I'd like to see in new minor versions, so I think that's pointing to us needing to remove interfaces from the public API surface because they prevent these kind of things from being possible.

[stebet]

Is there also a good reason to have interfaces for the basics like IConnection, IModel etc.? Don't really see a reason why anyone would go through the trouble of implementing their own version of those.

[bording]

Is there also a good reason to have interfaces for the basics like IConnection, IModel etc.? Don't really see a reason why anyone would go through the trouble of implementing their own version of those.

When I see interfaces used like that, it's usually an attempt to make testing easier since you can provide fake testing implementations.

[michaelklishin]

I'm not going to lie it is seriously annoying to me that we cannot ship new small features like this quickly in this client because of the adopted semantic versioning interpretation.

There is so much code out there that uses interfaces that removing them seems unrealistic.

[michaelklishin]

I suggest then that we only release new majors and patch releases, no minors. Minors make no sense in the world of strict semantic versioning: even small features often require some kind of interface changes, even minor usability improvements can be interpreted as breaking behavior changes. If almost no change is appropriate for a minor release, why bother with them at all?

[rwkarg]

Is there also a good reason to have interfaces for the basics like IConnection, IModel etc.? Don't really see a reason why anyone would go through the trouble of implementing their own version of those.

For context, we have a SharedPublishConnection and a SharedConsumerConnection implementation of IConnection that we use to enforce that publish and subscribe happen on separate connections/sockets (to avoid TCP backpressure on consumers in case of backlogs) as well as to enforce a single publisher and single consumer connection per endpoint/connection config (to avoid unnecessary TCP connections).