Cannot update or delete Cache Groups with null latitude and longitude

[ocket8888]

This Bug Report affects these Traffic Control components:

• Traffic Ops

Current behavior:

The API does not require a latitude and longitude when creating a Cache Group. Omitting those properties (or setting them to null explicitly) in the POST request to create a Cache Group does not result in an underlying "coordinate" being created for the Cache Group. A further PUT request to change, e.g. the Name of the Cache Group will cause a segmentation fault as Traffic Ops tries to dereference the null ID of the coordinate associated with the Cache Group during the update process. The request then fails even if otherwise well-formed, with a 500 Internal Server Error response.

Expected behavior:

If coordinates are to be required in requests, then omitting them (or setting them to null) in requests should return a client error code and an appropriate alert. If coordinates are not intended to be required, then the handler for PUT requests should not assume they exist and appropriately handle the case that they don't.

Steps to reproduce:

1. topost -k cachegroups '{"name": "test", "shortName": "test", "typeId": 23 (replace 23 with the ID of any Type that has a useInTable value of cachegroup)
2. toput -k cachegroups/10 '{"name": "test", "shortName": "test", "typeId": 23}' (replace 10 with the ID of the Cache Group created in step 1. and replace 23 with the ID of any Type that has a useInTable value of cachegroup)

Note that changing anything is unnecessary to encounter the bug.

It's unclear (to me) if this is a regression or not.

[ocket8888]

Even more annoyingly, I can't even get rid of the Cache Group, because DELETE requests fail for the same reason. Combined with being unable to update it to add coordinates, a Cache Group created with no coordinates is both immortal and immutable.

[ocket8888]

For the reasons stated in #2566, this is high impact, at least until #2566 is closed (either by making latitude and longitude required, which would also fix #2566, or by changing it such that null/undefined is a synonym for 0, which would close #2566 as "wontfix")

[srijeet0406]

@ocket8888 I can take this one.

[ocket8888]

This was closed by #6442