trafficcontrol: TO go client: login broken

This sounds like a much better solution to me than switching back the api version used by the client. 501 really should be in place for all endpoints beyond the currently implemented version. The 401 was totally confusing.

@jrushford @mitchell852 @dangogh How would you feel about this solution: what if we made hitting an API version that doesn’t exist always return 501 Not Implemented, and then further changed the TO client to always check for that code, and return it in the error from every client function?

It seems like that would mitigate a lot of the confusion around client/server versions, for people using master around the time a version change occurs.

In routes.go, I see

{1.1, http.MethodPost, user/login/?$, login.LoginHandler(d.DB, d.Config), 0, NoAuth, nil},

which to my understanding meant any of these should work fine:

POST api/1.1/user/login POST api/1.2/user/login POST api/1.3/user/login POST api/1.4/user/login POST api/1.5/user/login POST api/1.6/user/login POST api/1.7/user/login POST api/1.8/user/login POST api/1.9/user/login

It doesn’t work that way. The traffic_ops_golang router will serve all minor endpoints at all newer versions which exist. That’s important. If we served old endpoints at minors which didn’t exist, a client (like now) which is newer than the server would hit an endpoint which had been modified in 1.4, say DeliveryServices had a new field added, and that field wouldn’t exist in the server, and the client would return a struct with a nil or default value, and now the user thinks that value was nil or 0, when in fact they’re hitting an old TO.

The level of errors and confusion that would cause would far exceed the frustration of having to downgrade the client.