Add Layer2 protocols

[hercule-karuha]

The AF_PACKET domain has already been added.
But without ETH_P_ALL or other eth protocols, we still can't receive or send datalink layer packets.
Is it possilbe to add L2 protocols?

[Thomasdezeeuw]

Sure more constants for Domain would be accepted.

[boris-n]

I think this is more than just some constants. I made some first implementation but I want to discuss before I provide a pull request.

1. Protocol number:
   The Linux socket function "overloads" the protocol parameter: For AF_INET/AF_INET6 sockets, this is an IANA registered protocol number (or 0 for TCP or UDP); for AF_PACKET sockets, this is an IEEE 802.3 protocol number (aka Ethertype) in network byte order.
   Issue: Socket2 uses a "Protocol" type for this parameter which supports debug output, but this overloading can does not make the transformation unique without the socket family.
   Question: Do we want to add a different type (e.g. PacketProtocol) for AF_PACKET sockets (and then a different constructor, e.g. Socket2::new_packet_socket(...))? Or ignore the debug feature for Protocol? Other proposals?
   Question: Do we define the constants already in network byte order?
   Question: Which of the constants do we want to provide in socket2? There are many defined in Linux (see ETH_P_* constants in /usr/include/linux/if_ether.h), do we want to provide all?

2. SockAddr:
   AF_PACKET sockets use a "struct sockaddr_ll", so we need support for this in the struct SockAddr. A new constructor which creates a packet SockAddr will be needed, which then requires some new types (PacketProtocol, HwAddrType, PktType). A function to convert to sockaddr_ll will be needed for the implementation.
   For IP/IPv4/IPv6, SockAddr has no accessors to the fields; instead, it provides functions to convert to std::net::SocketAddr/V4/V6. How do we want to do this for sockaddr_ll fields?
   Question: Do we want to provide accessors to sockaddr_ll fields in SockAddr? SockAddr does not provide them for the sockaddr_in/sockaddr_in6 fields. Or do we implement a struct SocketAddrPacket with accessors and a conversion to it? This would be orthogonal to the sockaddr_in/sockaddr_in6 handling and will allow to access the fields directly (i.e. no Option return to handle the case that the SockAddr is not a sockaddr_ll) but will require copying of the sockaddr_ll fields.

Any comments would be welcome.