Wrong byte order swapping on IPv6 flowinfo and scope_id

[faern]

This crate uses ntoh (network byte order to host byte order) when picking out the sin6_flowinfo and sin6_scope_id from SOCKADDR_IN6_LH in ptrs_to_socket_addr:

miow/src/net.rs

Lines 554 to 555 in 37225af

	ntoh(b.sin6_flowinfo),
	ntoh(*b.u.sin6_scope_id()),

According to the Microsoft documentation these fields should indeed be "network-byte-order (big-endian)". But I don't think their documentation is correct.

Other libraries simply using them as host byte order

• The standard library:
  • PR changing it (back in 2016): std: Store flowinfo/scope_id in host byte order rust-lang/rust#32429
  • Current code: here and here
• net2 - https://github.com/deprecrated/net2-rs/blob/77a6eb4d5eb36adc81ee21ab7ffebc62fdf2ab88/src/socket.rs#L131-L136

This makes it so that if you call:

let addr1 = SocketAddr::V6(SocketAddrV6::new(ip, port, 1, 2));
let (addr_ptr, addr_len) = socket_addr_to_ptrs(&addr);
let addr2 = ptrs_to_socket_addr(addr_ptr, addr_len);

You end up with addr1 and addr2 being different. I guess one reason why this has not been discovered earlier is that flowinfo and scope ID very often are zero.

Yes, I did change the implementation of socket_addr_to_ptrs very recently (#39). But the same issue was there before my change. Because before my change that function just casted what the standard library had created, and the standard library does not store these fields as big endian.

[faern]

Some very basic testing with sockets in the standard library shows that if I bind to a link local IPv6 address, it does handle the scope_id correctly (it is set to the interface index). That's one reason why I think the standard library does the right thing. But I don't know very much about scope_id at all, and even less about flowinfo. So I could not tell. Mostly noting that miow does it differently from the rest of the ecosystem.