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 default into bug25428
Merge bug25428