usnic cagent: correctly compute the "large" ping message size

The (effective) "+42" computation was, in fact, the incorrect answer
in this case (gasp!).

We should just take the max_msg_size from the command (which came from
the libfabric endpoint max_msg_size attribute in the client) and
subtract off the max header size: 68 (which is explained in the
comment).  This will result in a "large" message size which is likely
slightly smaller than the MTU, but still right up near the MTU, and
therefore good enough.

Note: the old computation (i.e., -(68-42)) worked fine when we asked
for Libfabric API v1.1 because the usnic provider would return a
max_msg_size that was already less than the MTU due to FI_PREFIX
behavior shenanigans.  Once we started asking for Libfabric API v1.4,
the usnic Libfabric provider started returning (MTU + prefix_size),
and the -(68-42) computation started giving a value that was over the
MTU.  This caused sendto() on the connectivity checker UDP socket
to fail.

This commit also removes an old/misleading comment.

Signed-off-by: Jeff Squyres <jsquyres@cisco.com>

opal/mca/btl/usnic/btl_usnic_cagent.c

@@ -877,9 +877,8 @@ static void agent_thread_cmd_ping(agent_ipc_listener_t *ipc_listener)
        all IP options are enabled, which is 60 bytes), and then also
        subtract off the UDP header (which is 8 bytes).  So we need to
        subtract off 68 bytes from the MTU, and that's the largest ping
-       payload we can send.
-       max_msg_size allows for minimal UDP header, be more conservative */
-    ap->sizes[1] = cmd.max_msg_size - (68 - 42);
+       payload we can send. */
+    ap->sizes[1] = cmd.max_msg_size - 68;
 
     /* Allocate a buffer for each size.  Make sure the smallest size
        is at least sizeof(agent_udp_message_t). */