Update demo_ingress to expect a reads service name instead of managing services

[sjahl]

This addresses an issue that Phil ran into earlier this week after we rolled out reads using the new deployment methodology. Spinning up demos depended on being able to ask the k8s API what the current reads deployment was, and then generated a new Service object for you. Often times this just ended up being a new Service object called "gnomad-reads-demo-foobar" that pointed at the current production deployment pods, which didn't feel particularly useful.

I thought about this for a bit, and decided that managing the extra service object here was probably unnecessary? With these assumptions:

• If you don't care which reads service you get and just want to point at prod, there's already a Service you can wire up the ingress to
• If you do care which reads deployment your demo uses, you probably already spun one up and have a Service to point at it?

With those in mind, I've updated this script to just accept a reads Service name, and it uses that to configure the ingress instead of creating a bunch of extra Services. If you don't specify a service name, it just points /reads on your demo to the active prod service.

How do folks feel about that process, and are those assumptions I've made correct?

[sjahl]

Closes #1342

[phildarnowsky-broad]

@sjahl sounds like a sensible way to do it to me

[sjahl]

Note, I've tacked the new demo/spot pool changes into this PR, since it felt quite related.

We have a new CLI flag in deployctl deployments create. You can now pass the --demo flag to set your deployment to use the new auto-scaling demo-pool with spot nodes.