Implement SIOCGETSGCNT_IN6 ioctl

[eqvinox]

Unfortunately this isn't really done as-is since the ioctl value does not uniquely identify this ioctl. Some way to check the socket AF is needed to disambiguate :(

---

If someone with more experience in hacking on rr could take this off my hands that'd be much appreciated… I'm not sure I can dig through to implement figuring out the socket's AF

[rocallahan]

If you extend this PR with testcases for IPv4 and IPv6, I can implement the socket-family tracking. Basically we're going to need a new subclass of FileMonitor, SocketMonitor, that carries the socket domain.

Another approach would be to get the inode number by reading /proc/<pid>/fdinfo/<fd> and then scan /proc/net/tcp(6) and /proc/net/udp(6) (and maybe more) for that inode number. SocketMonitor will be generally faster and cleaner (but can fail e.g. if the socket fd was delivered to the tracee over another socket, and the sender is not being recorded by rr).

[khuey]

Attaching a FileMonitor subclass to every socket fd would be less than ideal because it would disable syscall buffering for them.

[rocallahan]

Attaching a FileMonitor subclass to every socket fd would be less than ideal because it would disable syscall buffering for them.

We could do something like FD_CLASS_PROC_MEM to fix that.

Another approach here might be to just ignore the socket family and treat everything as IPv6. Looks like that will mostly work since the IPv6 buffer is always longer than the IPv4 buffer and it's mostly OK to record more than we need. We would want to handle the case where the IPv4 buffer is at the end of a memory mapping so we can't record all of it.