Use the Connection Buffer for Writing

[julienschmidt]

Instead of allocating multiple small new slices and copy them in one big slice before sending (current approach) or the 2-Pass approach (Pass 1: getting the total size; Pass 2: packing in a new allocated slice with perfect size) in #71, this PR introduces yet another approach:

The connection buffer (currently only used for reading) is used for packing until the the buffer gets too small. At this point we (the builtin func append) start allocating bigger slices. This happens only for very large Queries since the buffer is by default 4KB large and can grow.
When the packing is finished, we can get the total size and write the packet header.

As a result, most packets can be built without making a single allocation, which results in a lot less garbage and a increased execution speed.

[arnehormann]

Everywhere this is used in packets.go, it's immediately followed by if data == nil based error handling, so even if it's inlined by the compiler, it always branches twice. b.length != 0 is the only way this can return nil, so I say manually inline all occurrences (and add a comment), use the buffer directly and drop the superflouus if for all 4 occurences.
That's bad from a code style perspective, but the comment should suffice. It will probably be a little faster and not more complex than it is now.

[julienschmidt]

Branches are not generally evil. In this case 1 branch miss is to be expected. I think keeping the buffer logic separate is worth it.

[arnehormann]

drop else, deindent (though it's not originally part of this PR)

[arnehormann]

Done so far (oof), eager to TAL 😀

[arnehormann]

Independent of else perception differences: LGTM