This fixes a BUG in the handling of the cum-ack calculation. We were only paying attention to the nr-mapping-array. Which seems to make sense on the surface, by definition things up to the cum-ack should be deliverable thus in the nr-mapping-array. However (there is always a gotcha) thats not true when it comes to large messages. The stack may hold the message while re-assembling it not not deliver it based on several thresholds. If that happens (which it would for smaller large messages) then the cum-ack is figured wrong. We now properly use both arrays in the cum-ack calculation.
This fixes a BUG in the handling of the cum-ack calculation.
We were only paying attention to the nr-mapping-array. Which
seems to make sense on the surface, by definition things
up to the cum-ack should be deliverable thus in the nr-mapping-array.
However (there is always a gotcha) thats not true when it
comes to large messages. The stack may hold the message
while re-assembling it not not deliver it based on several
thresholds. If that happens (which it would for smaller
large messages) then the cum-ack is figured wrong. We
now properly use both arrays in the cum-ack calculation.

MFC after:	1 week.

jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase