remove spurious generality
after spending hours trawling through the qi code and its history,
Matthew and I are convinced that qi:add_to_journal/3 is unnecessarily
general, handling a case that can never arise, namely adding an 'ack'
when we do have an entry for the given sequence number but that entry
does no contain a 'del'.

add_to_journal/3 gets called, indirectly, from four places:

1) load_journal/1. This is always called with no segements in the
State. So all the segment journal entries originate from the very
add_journal/3 code. And the only way we'd end up with an entry of the
form {Pub, no_del, no_ack} and get an 'ack' is if the journal
contained a pub and (later) an ack, with no del inbetween. That can
only happen through a misuse of the qi API. Which doesn't happen. And
there are plenty of other cases (e.g. duplicate dels or acks) where qi
insists on callers doing the right thing.

2) publish/5
This ends up adding a {?PUB, no_del, no_ack} entry, so is of no
direct concern to our investigation.

3) deliver_or_ack/3
This would hit the aforementioned {Pub, no_del, no_ack} & 'ack' case
only if we lost a 'del'.

4) recover_message/5

this only adds an 'ack' to the segment journal if either a) the
combination of the segment entries and the segment journal produces an
entry {?PUB, del, no_ack}, or b) it's just added a 'del' (thus making
a {Pub, no_del, no_ack} entry impossible). Re (a)... for there to be a
combined entry of {?PUB, del, no_ack} when the segment journal
contains {Pub, no_del, no_ack} (which would trigger the case we are
concerned about), the segment would have to contain a 'del' w/o a
'pub', which is impossible.
remove out-of-date comment
only keep track of *unconfirmed* unsync'ed messages ids in qi
...so we don't bloat memory with stuff nobody cares about, and reduce
the qi->queue callbacks (to zero when no confirms/tx are used)

This does expose qi to a bit more messaging semantics, but imo to an
acceptable degree.

related changes:
- rename the state var to better capture its (revised) meaning
- only invoke the OnSyncFun when we have something to say
don't hold on to 'complete' in-memory qi journal entries
When a pub, del and ack for a message are all recorded in the journal
then we don't bother writing any of that to the segment files when the
journal is flushed, since the message is well and truly in the past
and forgotten. So... there is no point keeping the entry in the
in-memory journal either, where it just eats up space until a flush
for no good reason.
reduce the default qi journal size
a large journal size improves performance by
- writing larger blocks to disk in one go (since in many scenarios we
  end up writing the entire journal in one go)
- reducing fsync frequency (since in many scenarios we only sync when
  rolling the journal)
- records for messages which get published, delivered and acked in the
  lifetime of a journal don't need to be written to segment files. To
  the point where we may be able to skip writing segment files
  altogether.

BUT a large size also has downsides:
- increased memory consumption
- increased amount of data loss in the event of a crash

So how do we pick a figure? Well, ultimately we may want to
dynamically adjust the size based on memory pressure, but that is a
fairly involved / risky change. Meanwhile, what would be the *lowest*
figure that still delivers all of the benefits, just somewhat less
than currently?

A single qi segment holds entries for 16k messages. We want the
journal to be able to hold at least an entire segment's worth of
publishes, delivers and acks, which would be 16k x 3 entries. That way
the aforementioned segment write reductions can happen when the queue
is small.

However, with a size of *exactly* 16k x 3, we would generally
only avoid whole segment writes when messages get published, delivered
and ack'ed straight away, which only happens when consuming in noack
mode from empty queues. So we want to add some headroom in order to
extend the benefits to a wider range of modes of queue operation.

Hence 16k x 4 is a good choice. It should allow most "near empty" fast
moving queues to avoid segment writes.
merge bug25428 into bug25429
ask qi whether it needs sync'ing, and why
merge default into bug25428
Merge bug25428
merge bug25428 into bug25429
Added tag rabbitmq_v3_0_2 for changeset bf11b947abb9
rabbit_parameter_validation:enum/1
We depend on xmerl via mochijson2.
Slightly cleaner logging at startup: don't repeat the RabbitMQ or Erlang versions, and split copyright out into its own log message since it is not like the other bits.
Merged bug25435 into stable
Slightly cleaner logging at startup: make the plugin list look nicer.
Spelling
Merged bug25433 into default
Remove durable queues based on a node while forgetting that node.
Only delete queues for which no HA policy exists.