Implement a '--backend' flag to run a server in the background

[anko]

Why?

This would be helpful for testing some types of programs:

• Programs that require a long-running server process to be running in the background, like web services.
• Interpreters that have a relatively long start up time. These could gain performance by feeding test code into a single process and evaling it, rather than starting one instance of the interpreter per test.

Current workaround

Use --jobs 1, and in your !program, start the backend if TXM_INDEX equals TXM_INDEX_FIRST, or stop it if TXM_INDEX equals TXM_INDEX_LAST.

For any other value of --jobs, this workaround introduces a race condition due to non-deterministic ordering.

How it could work

Before running the first test, start the program specified as --backend="program goes here" in the background. After the last test, terminate it.

If the backend program exits at any point, fail all so-far-incomplete tests. In the YAML for the failures, give the backend program's text, stdout, stderr, and exit code.

Limitations

Q: How do we know when the backend is truly "up" and ready to receive the first test?
A: We can't; it's application specific. We should document that it's the user's program's responsibility to deal with it.

[anko]

Good news: Implemented in the backend-flag branch. Tests work locally.

Bad news: Fails on Travis, hanging without explanation on the first associated test. Theories:

• Is waitOn blocking forever?

  → No. It's given a timeout option so it should throw.

  txm/test.ls

  Lines 1446 to 1454 in 63f2baa

  	// Wait for up to a second the server to start, then fetch the URI
  	// and print it.
  	waitOn({ resources: [ uri ], timeout: 1000 }, (error) => {
  	if (error) throw error
  	http.get(uri, (res) => {
  	res.pipe(process.stdout)
  	res.on('end', () => { process.stdout.write('\\n') })
  	})
  	})

• The server is binding to an IPv6 interface but the client is hitting IPv4 or vice-versa?

  → No. The server binds to localhost:8888,

  txm/test.ls

  Line 1481 in 63f2baa

  .listen(8888, 'localhost')

  and the client reads from localhost. Even if Travis has localhost set to something insane, waitOn should throw when it can't find anything.

Needs more investigation.