Go: Allocate less in indexed message chunk loading

[wkalt]

Prior to this commit, when reading a chunk into memory we would read it (internally, in io.ReadAll) into a resizing buffer and need to resize it several times up to final size. Since we know the final size in advance we can preallocate and save those allocations/copies.

[wkalt]

simple timings

main

[~/work/mcap/go/cli/mcap] (main) $ time mcap cat cal_loop.mcap > /dev/null
real    0m5.047s
user    0m4.719s
sys     0m1.083s

patch

[~/work/mcap/go/cli/mcap] (ticket/fg-4715/reader-less-allocs-go) $ time mcap cat cal_loop.mcap > /dev/null

real    0m3.084s
user    0m2.716s
sys     0m0.532s

40% faster

[wkalt]

lz4 numbers

main

[~/work/mcap/go/cli/mcap] (main) $ time mcap cat cal_loop.lz4.mcap > /dev/null

real    0m3.802s
user    0m3.563s
sys     0m0.622s

patch

[~/work/mcap/go/cli/mcap] (ticket/fg-4715/reader-less-allocs-go) $ time mcap cat cal_loop.lz4.mcap > /dev/null

real    0m2.372s
user    0m2.151s
sys     0m0.354s

[wkalt]

it seems like there would be further savings if we could reuse the chunk buffers, but I think this is too complicated by the heap. I also noticed the Next() method still takes a buffer which is now unused (I think originally that was passed to the lexer's Next method to conserve allocations) but I think resurrecting it is complicated now. Maybe we can sunset it, or maybe it actually is used for the unindexed iterator (need to check).

[wkalt]

last commit shaves a bit more off

[~/work/mcap/go/cli/mcap] (ticket/fg-4715/reader-less-allocs-go) $ time mcap cat cal_loop.mcap > /dev/null

real    0m2.734s
user    0m2.527s
sys     0m0.286s

[wkalt]

with final commit, I got a

[~/work/mcap/go/cli/mcap] (ticket/fg-4715/reader-less-allocs-go) $ time mcap cat cal_loop.mcap > /dev/null

real    0m2.515s
user    0m2.374s
sys     0m0.219s

which is close to 50% better than the first observation

[wkalt]

there is still some preexisting issue with very large inputs, where reading becomes sluggish after a while. I need to debug it further to understand what is happening. Won't merge this til I understand better.

[wkalt]

ok I think ^^ is just my terminal emulator, I verified with pv there's no actual slowdown and if I use xterm it appears to read at a consistent speed too. Merging.