WIP: Web terminals

See gitlab-org/gitlab-ce#25990 for the feature scope and specifications.

What does this MR do?

This adds a websocket server to Runner so it can proxy connections to any executor - this MR includes implementations for the Shell and Kubernetes executors. At a high level here's how this works:

• Runner starts up terminal server at a given host:port - code
• The address of this server is passed along in the registration request, so external clients know how to contact it - code
• When a new build starts, a pointer to the corresponding executor is stored in a global Executors set, so we can find the Executor for a given build - code
• When a new websocket request comes in to /?build_id=<id>, it is routed to the corresponding Executor's ConnectTerminal method which can handle it however it wants - code
  • In the case of shell executor, it proxies a file descriptor corresponding to an interactive shell - code
  • In the case of Kubernetes, it proxies websockets exactly like workhorse does for environments - code
• If the user is still connected when the build completes, it waits for either the session timeout or client disconnection, whichever happens first - code

What's missing in this MR

• Authentication - I can add JWT auth similar to workhorse, but I don't know how to share the secret between workhorse <=> runner. It looks like workhorse does it via a .gitlab_workhorse_secret file in gitlab's root dir, how is that created?
• Most of the terminal package code has been copied over as-is from workhorse - I plan to extract this into a common gitlab-terminal package that both workhorse and runner can leverage. Any thoughts / opinions on how I should go about doing this?
• Tests for timeout/disconnection in Kubernetes executor, similar to shell executor. I have them written locally but they're a bit flaky because of timing sensitivity. Any ideas to solve this?
• I didn't commit the vendor code for new dependencies because it would blow up the diff in this MR - is there a better way to handle this? (this is why the pipeline is failing currently)

@ayufan it would be great if you could help me out with these 🙂

Are there points in the code the reviewer needs to double check?

Default values for TerminalServerAddress and TerminalMaxRetentionTime in config.go

Does this MR meet the acceptance criteria?

• Documentation created/updated
• Tests
  • Integration tests for shell executor
  • Integration tests for Kubernetes executor
  • Other
• Branch has no merge conflicts with master (if you do - rebase it please)

What are the relevant issue numbers?

gitlab-ce#25990