CNET Chnls: deterministic protocol finding

[jalalmostafa]

The initialize_chnl and cnet_protosw in the channel(int, int, int) function can encounter bugs if the input to the channel is wrong.
Assume the user input of type arg in channel is equal to 10002 or the value of SOCK_CLOEXEC | SOCK_DGRAM:

• cnet_protosw_find will accept the value (even if it is wrong) just because of casting from 4B signed int of channel arguments to 2B unsigned int of cnet_protosw_find arguments. The function will return that the desired protocol is SOCK_DGRAM even if it might not be. Any value that can result in 2 when cast to uint16 will have a correct value even if this is not the desired behavior. A simple mitigation is to prevent casting, especially since higher-level APIs like channel use int not uint_16.

• initialize_chnl also sinks all non-DGRAM and non-ICMP6 channel types as TCP. This can be problematic if cnet_protosw_find returns a wrong value. I also think it is neater to check the protocol here and not only assume it will be TCP, for future protocol additions and integrity.

The branch also has minor log fixes.

[KeithWiles]

Looks good thanks.