extract all channel and consumer related queue functionality

design decisions:

- all limiter interactions take place in the new module. The
  alternative would turn into spaghetti and leave more code in
  amqqueue_process.

- asynchronous channel interactions - namely delivery of messages and
  'drained' events - happens in the new module whereas all other
  operations - really just sending of replies - takes place in
  amqqueue_process. I'm still in two minds about that. It would
  actually be simpler to have the rabbit_channel:deliver code in
  amqqueue_process, albeit in an existing closure, but send_drained is
  rather deeply embedded.

- we need a few functions in the API that manipulate the channel
  record. They all require the same kind of post-processing to invoke
  decorators, run the message queue, etc. I decided to make this
  pattern explicit in the API by having just one function there -
  queue_consumers:possibly_unblock - that takes a closure. It has just
  one call site - amqqueue_process:possibly_unblock - that contains
  the post-processing logic. The closures are constructed by four
  separate API functions.

There are a few complications...

1) event emission and decorator notifications

These are deeply embedded in some places and need to be lifted out so
they are all in the one logical place where they belong, namely
amqqueue_process. In some cases this complicates the API and code a
fair bit since we, e.g., need to collate information for subsequent
decorator notification. This is doubly annoying since the existing
decorators don't actually make use of that information, so we should
really consider simplifying the decorator API.

2) message delivery logic

This is a fairly complex piece of code and it gets more complicated
still because a) of the above, and b) sending a message to a channel
requires the queue name, so we need to pass that in. We also need the
state, and indeed modify it, though this is done opaquely. And it
looks like we could just pass BQ & BQS instead.

3) handle_cast/credit

I reckon this should have been implemented with possibly_unblock. It
is now. The behaviour isn't obviously equivalent, so this needs
careful consideration. The old code would invoke 'unblock' when "(not
Drain or Len /= 0) and updated channel record is not blocked". By
contrast, the possibly_unblock logic, which is what the new code
invokes, invokes 'unblock' when the old channel record is blocked and
the updated channel record is unblocked. This would seem to be
logical, and it would be weird indeed if the credit code relied on any
different behaviour.

4) queue_consumer:add is a nine-arg function. urgh. Mind you, so is
the handle_call/basic_consume message.

There are some minimal refactors and cosmetic changes which should go
straight onto 'default' and thus reduce the distance to changes in
this bug.

0 files changed, 0 insertions, 0 deletions