automatically create IngressRoutes for routing incoming playback requests

Nobody has claimed this yet.

**What's the problem? (required)**
We need to figure out how to route incoming playback requests to horizontally-scaled ingest servers. Two use cases in mind here:

1. Routing incoming playback requests to Mist servers that automatically route to an origin
2. Routing "custom names" to go-livepeer/Mist, allowing for "vanity names" like `/stream/eli.m3u8`

Here's what I'm thinking so far.
* The API server gains the capability to automatically create Traefik `IngressRoute` resources that route e.g. `/stream/eli*` to the `prod-livepeer-{shard}` service or `/hls/{playbackId}` to the `mist-server-0` service.
* The first place this will happen is on mist-api-connector's `/stream/:id/setactive` endpoint. When a new Mist stream comes in, we will create a new route for `/hls/{playbackId}` to the appropriate Mist server. `mist-api-connector` will be provided with the pertinent service name that it can then pass to the API.
* Later on this can also happen in the `/api/stream/hook` endpoint so streams with "vanity names" can be implemented with go-livepeer.

Alternatives:
This creates a dependency on the availability of the local Kubernetes API for ingesting new streams. We could instead keep the `name --> service` mapping in our own API database and proxy the streams through the API. This would require us to write some manner of API-aware proxy and send all traffic through it. I like using Traefik instead, but it's important to keep the tradeoff in mind.

Start with mist-api-connector's /stream/:id/setactive endpoint and the API server's handling of Kubernetes resources. Trace how a new Mist stream identifies its target service and review the proposed IngressRoute paths for /hls/{playbackId} and future vanity names. Done means the routing design and its Kubernetes dependency are resolved for the stated use cases.

Written by the indexing model from the issue text.