LP#1970469: fix responses streamed out of order due to chunking

LP#1970469: fix responses streamed out of order due to chunking

If a streaming method starts off sending a couple small responses
followed by a large one, the responses can end up received out of
order under this scenario:

- The initial small responses get stashed to be sent out as a bundle
- The large response, if big enough to require chunking, gets sent
  out as a set of partial responses. However, any messages queued
  up to go out as a bundle remain in the queue.
- When the method completes, or if further responses result in
  exceeding the maximum bundle size, the queued messages get sent
  _after_ the chunked response.

This affects services written in C and Perl.

To test
-------

C service
=========
[1] Add the following stored procedure to an Evergreen database:

CREATE OR REPLACE FUNCTION public.lp1970469_sample() RETURNS SETOF TEXT AS $$
BEGIN
    RETURN NEXT 'abc';
    RETURN NEXT 'def';
    RETURN NEXT rpad('long', 65000, 'x');
    RETURN NEXT 'xyz';
    RETURN;
END;
$$ LANGUAGE PLPGSQL IMMUTABLE;

[2] Run the following srfsh command:

srfsh# open-ils.cstore open-ils.cstore.json_query.atomic {"from":["public.lp1970469_sample"]}

[3] Note that longxxxxx* response is returned first, followed by abc,
    def, and xyz.
[4] Apply the patch and repeat step 2. This time, the responses should
    be returned in the expected order.

Perl service
============
[1] In an Evergreen database, attach a couple hundred items to
    a record.
[2] Run the following srfsh command:

srfsh# request open-ils.supercat open-ils.supercat.record.holdings_xml.retrieve BIBID, "-", null, 1

[3] If enough items were attached, the first response streamed will
    start with a <volume> element rather than the <holdings> element
    and the overall response will not be well-formed XML.
[4] Apply the patch and repeat step 2. This time, the parts of the
    response should be in the expected order.

Note that this test scenario models an Evergreen glitch seen in the
wild that causes requests for

https://EGSERVER//opac/extras/supercat/retrieve/marcxml-full/record/BIBID

to fall if there are a lot of items attached to the bib.

Signed-off-by: Galen Charlton <gmc@equinoxOLI.org>
Signed-off-by: Mike Rylander <mrylander@gmail.com>