LU-10391 lnet: separate lnet_hdr in msg from that in lnd.

LU-10391 lnet: separate lnet_hdr in msg from that in lnd.

The lnet_hdr stored in an lnet_msg has fields which are sometimes in
le byte order and sometimes in host byte order.

The various lnds need all these fields to be in le byte order for
transmission or reception over the network.

To support larger (IPv6) NIDs, we will need the lnet_hdr in lnet_msg
to store these NIDs, but the lnd will need both 4byte-addr and 16-byte
lnds depending on protocol negotiation.

This patch separates out the two to make the conversion easier to
follow.

'struct lnet_hdr' is now used within common lnet code, and is not
stored in network buffers.

lnd_send will convert from 'struct lnet_hdr' to whatever is required
in the network buffer.  When lnet_parse() is called, the network
buffer will be converted to a 'struct lnet_hdr' first, and that will
be passed to lnet_parse().

The common fields of 'struct lnet_hdr' are always in host byte order.
The command specific fields (now in 'union lnet_cmd_hdr') have not
been changed and are sometimes host-byte-order and sometimes
l3-byte-order.

The new 'struct lnet_hdr_nid4' is used in network buffers.  It is
opaque - there are no subfields to access.  Very few places in the lnd
code want to access fields anyway.

New functions lnet_hdr_to_nid4() and lnet_hdr_from_nid4() can
convert between the lnet_hdr_nid4 to the internal lnet_hdr.

'struct _lnet_hdr_nid4' is provided to access fields inside 'struct
lnet_hdr_nid4' when that is really needed.  It is used by the to/from
functions and a couple of other places.

Test-Parameters: trivial
Test-Parameters: serverversion=2.12 serverdistro=el7.9 testlist=runtests
Test-Parameters: clientversion=2.12 testlist=runtests
Signed-off-by: Mr NeilBrown <neilb@suse.de>
Change-Id: I55277a49538543376cf0404f749d3357a2950a7c
Reviewed-on: https://review.whamcloud.com/43603
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Reviewed-by: Chris Horn <chris.horn@hpe.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>