Multi interface health

[ocket8888]

What does this PR (Pull Request) do?

• This PR fixes Enable Traffic Monitor to read in multiple interfaces for a cache server #4618

This removes the temporary shim "aggregate" interface used by Traffic Monitor - and Traffic Ops to a much lesser degree - and adds the ability to truly monitor cache servers according to both aggregate statistics as well as network interface thresholds.

Because interface stats now appear in cache stats TM API responses, this also introduces an equivalent to the stats query parameter used to filter general cache stats called interfaceStats.

This PR also properly wraps use of the Traffic Ops Go client in Traffic Monitor - for tasks requiring APIv3-format data (there are still some places where APIv2 is used explicitly) - such that if login fails with the current API version (3), login will be tried with the older version (2.0) and, if successful, all future requests will use API v2.0, coercing legacy data into modern structures as necessary - and there are unit tests for those coercions.

It also consolidates double-definitions of cache server interface information and IP address structures into one, and consequently moved some functionality between files as appropriate.

It also adds support for signed and unsigned integral values of cache statistics, which previously only allowed floating point-type numbers.

It also adds some table styling to the TM UI to fix error rows not highlighted in red - that's just a temporary, small workaround to ease testing of this PR, and a better fix is coming in #4746.

It also fixes a bug in a "CRConfig" Snapshot API unit test where the test was using servers without any IP addresses - it wasn't failing, but was merely not actually testing as much as it ought to have been.

It also fixes a bug when converting server interface data to the legacy format which would cause them to report an incorrect interface name under certain circumstances, adding a test.

It also fixes a bug parsing lib/go-tc.TMParameters structures from JSON with certain comparators in health thresholds, adding a test.

Finally, it also adds a load of GoDoc comments to objects that previously did not have them, and several tests for things that did not previously have those.

Which Traffic Control components are affected by this PR?

• Documentation
• Traffic Monitor
• Traffic Ops

What is the best way to verify this PR?

Run all unit tests - for /lib, Traffic Monitor, and Traffic Ops. Also ensure all of the Traffic Ops API tests - versions 1-3 - work and pass.

To test the interface monitoring behavior, given some set of cache servers monitored by the Traffic Monitor instance being tested, add dummy interfaces you're sure won't be in the returned health data from the cache servers' health polling endpoints. Ensure that when "monitor" is not true for this/these interface(s) that they don't affect health status setting for the cache servers. Ensure that when this changes ("monitor" is true) the Traffic Monitor marks the cache servers as unhealthy because it can't find any data for the interfaces in the polling data. Also, check that "maxBandwidth" limits on each actually poll-able interface is respected, by setting it to something lower than the interface is actually serving (I use zero, because that's nearly impossible to reach) such that cache servers are marked unavailable when they are exceeded, and are not - at least not for that reason - when they are not exceeded. Finally, check that there is no setting of "maxBandwidth" on any interface with "monitor" set to false that will result in the cache server being marked unavailable (again, I use zero).

If this is a bug fix, what versions of Traffic Control are affected?

• master

The following criteria are ALL met by this PR

• This PR includes tests
• This PR includes documentation
• This PR includes an update to CHANGELOG.md
• This PR includes any and all required license headers
• This PR does not include a database migration
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY

[mattjackson220]

Just a couple minor comments. TM unit tests pass, TO unit and API v1, v2, and v3 tests pass, /lib tests pass, docs build and look good. still testing functionality in ciab

[mattjackson220]

Looks really close to me. TO and TM unit tests pass, API tests pass, docs build and look good, manual testing works as expected.
only thing ive noticed is that all interfaces in /cache-statuses have the same bandwidth, making the total bandwidth off too. i think its a bug in cachestate.go lines 181-187. should use health[0].InterfaceVitals[inf.Name] data instead of lastStat?

[mattjackson220]

Looks good to me! lib, monitor, and ops unit tests pass, docs build and look good, v1 v2 and v3 API tests pass, testing in full environment all looks great!

[shamrickus]

LGTM
There are still a couple issues, specifically with upgrading ATC (#5001), but those will be resolved in a separate PR.