Rotate02

[cliffjansen]

the first commit does fewer buffer defrag/rotates in the case of outgoing deliveries.

the second takes advantage of code of first to promote more fairness in scheduling

third makes many calls to buffer defrag more performant. The first commit ensures that an outgoing delivery is never wrapped, so this optimization always applies. The special case of cj-sender runs > 10x faster, but streaming messages should in aggregate enjoy a performance boost or reduced cpu load.

[astitcher]

On the whole I really dislike this change: it complicates the code in a way that makes it harder to understand and doesn't introduce any abstractions to ease comprehension in any way.
I think we should only introduce this change if it gives us an observable performance improvement in real use cases.

[astitcher]

I think this logic is actually part of the _rotate function and should be there.

Also our code formatting has the braces explicitly present for this format of if:

if (...) {
  ...
} else {
  ...
}'''

[astitcher]

There are 2 use cases for pn_buffer_t:

1. As an intermediate buffer in the output logic chain. In this usage I'm pretty sure that we can stop automatically defragging the buffer and only do it on a specific request. In this world the pn_buffer_bytes API can obviously only return one contiguous segment of the buffer, but there can only be 2 of them so instead of using pn_buffer_bytes once to get the whole buffer using it twice in succession will get both segments if the buffer has wrapped.
2. As a hacky way to manage a grow only buffer that is never in practice defragged anyway - I think all uses of ```pn_buffer_memory`` are like this. We should just introduce a new buffer api for these cases.

[cliffjansen]

Thanks for taking a look.

I will try to rework this as suggested.