If the []Attr slice passed to Conn.Entry was used in several concurrent
calls, and it had sufficient capacity that append()ing to it succeeded
without reallocating the slice, then a data race would exist.
Fix this, and fix the efficiency gotcha which expected the attribute
slice to have additional capacity, by instead always constructing a new
final slice of []Attr and using a sync.Pool to avoid reallocating them.
Fixes go test -race, and improves the benchmark. Before:
goos: linux
goarch: amd64
pkg: src.lwithers.me.uk/go/journal
cpu: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
BenchmarkEntry-8 8345163 2139 ns/op 848 B/op 15 allocs/op
PASS
ok src.lwithers.me.uk/go/journal 20.034s
After:
goos: linux
goarch: amd64
pkg: src.lwithers.me.uk/go/journal
cpu: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
BenchmarkEntry-8 12611158 1445 ns/op 221 B/op 7 allocs/op
PASS
ok src.lwithers.me.uk/go/journal 19.673s
Laurence Withers