Allocate much larger buffer for event data, remove incorrect logic

[stolowski]

We have recently been alerted about an issue where go-udev returns the following error: udev event error: Unable to parse uevent, err: no buffer space available (see https://bugs.launchpad.net/snapd/+bug/1833707).

The reference implementation of udev monitor coming from systemd uses a large buffer for events - see https://github.com/systemd/systemd/blob/master/src/udev/udevadm-monitor.c#L73 ; while go-udev implements logic for resizing the buffer, it is based on a wrong assumption regarding MSG_PEEK flag; the meaning of the flag is simply the following:

"This flag causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue. Thus, a subsequent receive call will return the same data."

This PR pre-allocates the buffer based on reference implementation from systemd, and removes the resizing logic. Also, the allocation is moved to the Connect method so it's done only once.

I think that maybe MSG_PEEK should be OR'ed with MSG_TRUNC flag and then the resizing logic would work, but I'm not able to reproduce this error case, so I chose a conservative fix.

[stolowski]

Please hold on with reviewing this, the problem may be actually deeper and existing logic based on MSG_PEEK may be correct after all... Discussing this with my peers.

[stolowski]

Closing, problem caused by low value of /proc/sys/net/core/rmem_default size. Sorry for the noise!