Update the comment to be more concise.
Implement rss_gethashconfig() - return the currently supported hash methods
by the stack.

Right now the stack isn't really setup for RSS with 4-tuple UDP hashing
for either IPv4 and IPv6.

The specifics:

* The UDP init path udp_init() and udplite_init() specify the hash as
  2-tuple, so the PCBGROUPS code only tries a 2-tuple check;
* The PCBGROUPS and RSS code doesn't know about the UDP hash types
  just yet, so they're never treated as valid hashes.
* For correctness, 4-tuple can't be enabled in the general case because
  UDP datagrams can be more fragmented than IP datagrams may be.

Strictly speaking, TCP datagrams may also be fragmented and this could
cause issues with PCBGROUPS/RSS until the IP defragment path grows some
code to re-calculate the RSS hash.

I'll follow this commit up with awareness of the UDP 4-tuple for those
who wish to configure it, but for now it'll stay disabled.

No drivers (yet) know to use this function when RSS is enabled.
Add hash awareness of the IPv4 and IPv6 UDP 4-tuple.

Note: it would be nice if the supported hash check would be used here!
Make the PCBGROUPS code aware of IPv4 UDP 4-tuple.
When it's time to do 4-tuple UDP IPv6 hashing, make sure this is a known
type.
Disable the ixgbe(4) UDP 4-tuple hashing for the time being.

A mix of fragmented and non-fragmented UDP in a single stream will end up
being hashed differently, resulting in out-of-order behaviour in the receive
path.

This was done in the linux e1000 driver in 2011.

Discussed with:	jfv
Teach ixgbe(4) about rss_gethashconfig().

If RSS is enabled, ixgbe(4) will query the RSS API for the types of hashes
which should be used.  It'll then only enable hashes that are exposed via
the RSS layer.

This way it won't try to do things like enable UDP hashing if RSS explicitly
states that it isn't supported in lookups.

Tested:

* 82599EB ixgbe(4) NIC
Add the UDP hash -> RSS mbuf hash type for the ixgbe(4) driver.