netlink: consider memoizing the largest seen buffer size in Conn.Receive

[mdlayher]

Right now we allocate a page of memory, peek into the socket, and double the size of the buffer if we can't fit the entire message.

For APIs which frequently return a large amount of data, it probably makes sense to memoize the largest used buffer on a per-Conn basis so that we know how much to allocate up front rather than looping with peek/allocate.

[mdlayher]

Before committing to doing this with a public API, I may do something along the lines of NLDEBUG=experiments=conn-memoize-receive or similar so this can be quickly toggled with no code changes in deployments.

[helios741]

I used netlink for internal services and optimized conn.Receive with sync.Pool, saving GCMark time and 28% CPU savings.
If possible, I can submit a PR to optimize conn.Receive.

Before optimisation:
CPU:

mem:

After optimization:
CPU:

Mem:

[mdlayher]

I don't believe a sync.Pool optimization would be safe because the library hands out allocated buffers for caller use, and putting those back in the pool could mean they are clobbered.

I think a more appropriate approach to reuse memory would be to add an API which reads into a caller-allocated buffer and leaves managing that up to the caller.

[mdlayher]

Closing in favor of #178.