Fix attach resize

[code-asher]

Previously we would spawn the daemon via -Dm then attach with -x once it
was ready. This had a flaw: the daemon starts with a hardcoded 24x80
size and when the attach comes in it resizes and leaves a bunch of
confusing whitespace above your prompt.

Now we skip the daemon spawn and go straight for the attach but with the
addition of -RR which lets screen spawn the daemon for us if it does
not yet exist.

Consequences:

1. We can only allow one attach at a time because screen has no problem
   creating multiple daemons with the same name.
2. IDs cannot overlap since screen will do partial matching when we do
   not include the PID which we no longer have.
3. We do not know when the daemon exits so cleanup only happens on the
   timeout.
4. We have to kill the session by sending the quit command through
   screen. When we do this it is possible the session is already dead.
5. If the daemon exits and the user reconnects before the timeout the
   daemon will be respawned all while the Go program remains blissfully
   unaware assuming it has been up this whole time. Does not change
   anything in practice, just a bit different in terms of underlying
   architecture.

In some ways this new architecture is actually simpler with roughly the
same functionality but it does not support concurrent attaches and theoretically
has a greater danger of desyncing from screen's own state (although at the
moment nothing concretely dangerous comes to mind).

[code-asher]

This can be experimented with here: https://github.com/coder/v1/pull/13400

[spikecurtis]

Generally looks good, but I have some concerns about leaking screen sessions or the goroutines that are meant to stop them.

[code-asher]

I think I got all the flakes:

• There was a 10 second timeout for each test which occasionally prematurely ended the test. Increase to 30 seconds.
• We wait almost exactly as long as it takes for the session timeout to hit. If the goroutine that deletes the session from the map has not ran yet we can end up grabbing a closed session. Add some code to create a new session when that happens by checking the state first.
• For similar reasons the heartbeat would fire after closing (since the goroutine that cancels the heartbeat may not have ran yet). Does not cause any flakes but seemed like something worth fixing as it starts off another timer which I assume will delay garbage collection.
• It seems we can also end up connecting just before the timeout kicks in and closes the session which gives us an existing session and breaks the new session test. To fix this decrease the timeout so we are definitely connecting after the timeout hits and the session closes. Technically this would mask the second flake if it was still an issue though which is unfortunate. Might need to refactor to not use time.Sleep() for these tests instead but maybe this is good enough for now.
• Lower the simultaneous connections test to 10 at a time. I kept seeing sessions terminating for apparently no reason (not from our code, they just terminated from screen’s end) and I think it was due to the number of sessions being spawned since I have not seen the same problem since lowering it. They do not look like OOMs so I think maybe there is a limit in screen or maybe it hits process limits in CI.