Force server ip addresses to include a cidr subnet

[jhg03a]

This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:

• Traffic Ops

Current behavior:

Currently TO has no restrictions on if or what cidr ranges may be applied to a server IP address. In some use cases and contexts this is required information, such as server provisioning. Humans are inconsistent however and don't always include this information either by accident or because they meant only a single ip address. Any downline TO API consumer has to include special parsing logic for IP addresses to handle cases where maybe it's included and maybe it's not. Depending on testing sample size and bad luck, you might not realize this is the case and end up throwing preventable errors.

New behavior:

I propose that for GET operations on the server object the lack of a cidr range should automatically append a /32 or /128 subnet accordingly in the event a cidr range is missing. This brings consistency to the output, while still allowing users not to have to think about it when they mean a single ip address. Given that any consumer of the API already has, or should, handle this inconsistency and either drop the cidr if they don't want it or glue it in if they do, this should be a safe change to make on an existing TO API version. This does not attempt to address if the cidr range provided by a human makes any sense such as /0. If it is more desirable for the data to be consistent in TODB, this could alternatively be applied as an input restriction on TO and TP along with a migration to correct existing data; thus forcing the user to think about their input more.