Wildcard domain handling means that the URLs constructed to access Workspace Apps like JupyterLab, RStudio, etc, encode the workspace ID and app name in the host portion. This is a blocker for many data science and V1 customers who need these IDEs

E.g. https://spike.dogfood.jupyterlab.dev.coder.com/ might represent the workspace spike/dogfood with the app named jupyterlab.

The deployment operator needs to register a wildcard DNS entry like **.dev.coder.com pointing to the Coder server IP, and also have a wildcard certificate if they're doing TLS (which they absolutely should).

Then, Coder server routes the HTTP requests to the appropriate workspace based on the Host header in the HTTP request.

Implementation Notes:

Should this be configured in the template, or on a per-cluster basis?

• Cluster operator might not have a wildcard certificate / DNS entry as these are expensive
• Certain apps seem to require this as indicated in the title
• Some apps can support both, but need to be correctly configured, e.g. RStudio according to @Emyrk
• Backend can probably accept either, simultaneously, but we still need to determine what URL to use on the front end

Acceptance Criteria:

???