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.

0 files changed, 0 insertions, 0 deletions