I'd like to propose we deprecate & remove the Traffic Ops ATS Cache Config endpoints. In fact, I'd like to propose we Deprecate in Master now, and in the following Major Release (5.0) that we remove the code and change the endpoints to return a 501 Not Implemented.
This follows the TC SemVer versioning deprecate schedule (giving users 2 major versions to upgrade ORT before the endpoints older ORT uses are removed); but does _not_ follow the API SemVer Version Promise and deprecate schedule. This is mostly breaking the Semantic Versioning API Promise. The endpoints would still exist, but they wouldn't be usable anymore. Normally, I'm the last person to ever want to break SemVer. But in this particular case, I think it's more dangerous not to. Because the Cache Configs have been moved to the client-side generator run by ORT, these endpoints are no longer used. I had hoped to move most of the code to a library, and I did move all the logic there. But unfortunately, what I found when I actually wrote the generator, was that a great deal of the code is loading data, not logic. The `traffic_ops/traffic_ops_golang/ats` directory has 5,300 lines of code. That's 5k lines which won't be well-maintained, because nobody will be using it, everyone will be using the ORT with the client-side generator. These endpoints also aren't regular user endpoints; generally speaking, nobody should be using them anymore, TC users should be using ORT which calls atstccfg. If someone does want to generate their own configs, you should use the lib/go-atscfg library calling regular data endpoints, not the TO config endpoints which aren't used or maintained. If someone really, really wants TO to still generate the endpoints (along with a different/modified ORT config deployment), you can still write a TO plugin to use lib/go-atscfg to create and serve configs. In summary, I don't take breaking users lightly, but I think the danger of keeping the unused ATS configs outweighs breaking SemVer here. Thoughts?
