Prevent loss of m_ipv6_socket attribute

[vladmovchan]

SocketFd::accept() always returns SocketFd object with m_ipv6_socket flag set to false. As the result SocketFd::set_priority() which called later on the same socket executes

setsockopt(m_fd, IPPROTO_IP, IP_TOS, &opt, sizeof(opt))

even for IPv6 sockets.

Linux tolerates this, but on FreeBSD such call on IPv6 socket cause error, and as the result following call chain fails:

frame #0: 0x0000000800595d72 libtorrent.so.20.0.0`torrent::SocketFd::set_priority(unsigned char) + 114
frame #1: 0x000000080059e05d libtorrent.so.20.0.0`torrent::HandshakeManager::setup_socket(torrent::SocketFd) + 125
frame #2: 0x000000080059deca libtorrent.so.20.0.0`torrent::HandshakeManager::add_incoming(torrent::SocketFd, rak::socket_address const&) + 90
frame #3: 0x000000080059562e libtorrent.so.20.0.0`torrent::Listen::event_read(void) + 94
frame #4: 0x000000080052d974 libtorrent.so.20.0.0`torrent::PollKQueue::perform(void) + 68
frame #5: 0x0000000800561a83 libtorrent.so.20.0.0`torrent::thread_base::event_loop(torrent::thread_base*) + 387

what causes immediate drop of any incoming connection right after it has been accept()-ed.

Syscall trace of this case on FreeBSD host:

accept(12,{ AF_INET6 [::ffff:127.0.0.1]:28543 },0x7fffffffddfc) = 161 (0xa1)
fcntl(161,F_SETFL,O_RDONLY|O_NONBLOCK)       = 0 (0x0)
setsockopt(161,IPPROTO_IP,IP_TOS,0x7fffffffdd9c,4) ERR#22 'Invalid argument'
close(161)                   = 0 (0x0)

For comparison same trace on CentOS 7 host:

[pid 15592] accept(13, {sa_family=AF_INET6, sin6_port=htons(60668), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 16
[pid 15592] fcntl(16, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
[pid 15592] setsockopt(16, SOL_IP, IP_TOS, [8], 4) = 0

This change fixes https://github.com/rakshasa/rtorrent/issues/786

[coveralls]

Coverage decreased (-0.02%) to 17.873% when pulling 0f957c2576d0d0c4c227e4453d92f67884e608af on vladmovchan:IPv6_patch into 3a6a61a4138048134f9048aef81a52f9bf821b29 on rakshasa:master.

[glebius]

Pretty sure the same problem as in pull request #179 . Not sure whose patch is better. I already don't remember details.