Remove duplicated checks of vhost queue limit

[SimonUnge]

Proposed Changes

#11222 moved the check of vhost queue limit to rabbit_queue_type:declare. I did miss that there are checks from other sources too, so I have updated those sources to reflect the changes. Basically removed the check, and handle the precondition error better.

This 'might' have changed the logging msg some, which might or might not be OK?

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)
• Build system and/or CI

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)
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution
you did and what alternatives you considered, etc.

[SimonUnge]

@ansd as per discussed in #11222. This PR changes some more uses of the limit check. The actual logging msg might have changed slightly - but now uniformed. If thats not OK, I can fix that...

[ansd]

Thanks @SimonUnge for spotting and updating all the other places too!
The changed log message is no problem.

[SimonUnge]

@ansd Thank you, I've updated the code to use a new atom for the limit error, with hopefully more unified error messages.

[SimonUnge]

@michaelklishin @ansd

I updated the code with a new protocol_error -> queue_limit_exceeded, and handle it in the code base. Not sure if we want the error code to change, and I felt a bit shaky added a new one to rabbit_framing_amqp_0_9_1.erl. So please take a hard look at those changes :) I could just map queue_limit_exceeded to precondition_failed too, if that would be more correct than to add queue_limit_exceeded to the amqp framing?

UPDATE: Actually felt too shaky messing with protocols like that, so I just did the mapping from queue_limit_exceeded to precondition_failed in rabbit_channel instead.

[michaelklishin]

Returning a Precondition Failed to the client when this limit is exceeded sounds perfectly fine to me simply because that's how most queue and stream declaration errors are communicated.

[michaelklishin]

@SimonUnge the Dialyzer failures seem legit and repeatable.

[SimonUnge]

@SimonUnge the Dialyzer failures seem legit and repeatable.
@michaelklishin
On it.

UPDATE: Ah, missed adding a file, so should pass now.

[ansd]

Thanks a lot @SimonUnge !

[michaelklishin]

@SimonUnge @ansd AMQP 1.0 topology management does not exist in v3.13.x but we can backport other relevant bits, if any.

[ansd]

Yes, I'll take care of the backport.