[RFE] More Useful Logging on validate_env.py for Network Validation

[sadsfae]

Current Scenario
validate_env.py --debug gives a user more detailed information of what might need to be addressed during validations of systems/cloud environments.

https://github.com/redhat-performance/quads#troubleshooting-validation-failures

In particular we print the internal interface IP addresses that are unreachable via the fping component of validate_env.py

In order to get the problem host we take the first two IP address octets and replace them with the CIDR octets used by the FQDN of that host.

e.g. 172.16.23.334 becomes 10.1.23.334 if we use a 10.1 octet for our systems FQDN network ranges for the provisioning network. We then can determine what host is in question by running host 10.1.23.334.

Proposed Enhancement

Augment validate_env.py to do the following:

1. Have the user enter an optional prov_interface_ip_octet_pair: value in quads.yml

e.g. prov_interface_ip_octet_pair: 10.1

We should also provide a mapping of second octet to interface names

internal_int_em1: 16
internal_int_em2: 17
internal_int_em3: 18
internal_int_em4: 19

2. QUADS then turns 172.16.23.334 into 10.1.23.334, and runs something like the following to obtain the FQDN of the host.

import socket
socket.gethostbyname('10.1.23.334')

3. QUADS via validate_env.py returns an additional message appended to the original error like:

ICMP Host Unreachable from 172.16.96.70 for ICMP Echo sent to 172.16.23.334
This might be e34-h03-000-r740xd.example.com - em2

Because we know that .16, .17, .18, .19 correspond to internal interfaces em1, em2, em3, em4 we can also suggest the interface that might have an issue on that remote host.

If prov_interface_ip_octet_pair: is empty then this suggestion is not displayed.

We will use default values above for all internal_int_em# variables above too and reflect this in a table in our documentation to better explain how validations and networks are related.