If the test controller tries to read the file while the server it has
started is in the middle of writing it, it gets invalid JSON and fails.
This just loops again until we have valid JSON to read.
this way those running the test suite can discover that there are a
bunch of js test groups. New output of `iptest -j` looks like this
```
Test group: kernel.inprocess -------------------------------------- OK
Test group: config ------------------------------------------------ OK
Test group: extensions -------------------------------------------- OK
Test group: lib --------------------------------------------------- OK
Test group: testing ----------------------------------------------- OK
Test group: core -------------------------------------------------- OK
Test group: terminal ---------------------------------------------- OK
Test group: utils ------------------------------------------------- OK
Test group: kernel ------------------------------------------------ OK
Test group: nbformat ---------------------------------------------- OK
Test group: qt ---------------------------------------------------- OK
Test group: autoreload -------------------------------------------- OK
Test group: html -------------------------------------------------- OK
Test group: nbconvert --------------------------------------------- OK
Test group: parallel ----------------------------------------- NOT RUN
Test group: js/base ------------------------------------------ NOT RUN
Test group: js/notebook -------------------------------------- NOT RUN
Test group: js/widgets --------------------------------------- NOT RUN
Test group: js/tree ------------------------------------------ NOT RUN
Test group: js/casperjs -------------------------------------- NOT RUN
Test group: js/services -------------------------------------- NOT RUN
```
It can encounter a weird segfault on OS X with sqlite when Qt is present (?!)
The main reason to use the fork was to get the port number,
but this is easy now that notebooks write a server-info file.
Further advantage is that the symptom of a failed server start
is no longer silence and hanging tests, but an actual failure with the server's log output.
Add a setup() method to be called when we know we're going to use a test
group, for creating temporary dirs etc., and a print_extra_info() method
to display extra information.
* Closing old pages to prevent fd leaks.
* Making sure kernels are killed to prevent fd leaks.
* Moving towards deleting old notebooks (this is not done, but
this should be merged as is).
This supersedes PR #4268.
Run the tests with '--subproc-streams show' to show output from
subprocesses (kernels, IPython.parallel components) in the terminal, or
with '--subproc-streams discard' to send it to /dev/null. By default (or
with '--subproc-streams capture') the output is piped, captured and
displayed only when tests fail. But in some situations, a test fails
because of an error which actually occurred earlier, so you have to see
all the output.