Defend against eavesdropping of worker tokens

In !616 (comment 495630), @hertzog mentioned that it would make sense to improve the way that workers authenticate to the server. At present, the worker generates a token, sends it to /1.0/worker/register/ when it starts up, and then sends it in an HTTP Token header when connecting to the server later. Passively eavesdropping on any part of this process would allow the eavesdropper to impersonate the worker.

Contrary to what Raphaël said in that comment, I actually think there's an argument that this will be less important for signing workers in the way that I'm currently designing them, because requiring HTTPS (or the websocket equivalent) for all communications between the worker and the server is already good protection against eavesdropping. Still, it would probably be worth improving this system.

I don't think we should do this in a hurry. This is essentially the problem of designing inter-service API tokens, and https://fly.io/blog/api-tokens-a-tedious-survey/ should give an idea of why that space has many tempting footguns. We could use the public key scheme Raphaël suggested, which I guess is similar to https://docs.saltproject.io/salt/user-guide/en/latest/topics/security.html (probably easier for websockets where we have good two-way communication, but awkward for HTTP). Or we could have a secret shared between server and worker, but use HMAC request authentication for the worker to prove its knowledge of the secret rather than sending it directly (though this still leaves the problem of communicating the shared secret in the first place, and I'm not sure how it works with websockets). If possible I'd like to find something mostly off-the-shelf that we can review and integrate rather than designing our own scheme here.