Merge lp://staging/~gary/launchpad/bug872089 into lp://staging/launchpad

[r=gmb][bug=872089][no-qa] bugfixes and improvements to the yuixhr test infrastructure

In the course of working on bug 724609, I have encountered some bugs, annoyances, and wishlist items when writing the new yuixhr tests. This branch addresses many of them.

 - There was a bunch of boiler plate that had to happen at the end of the JS file to get the test to run, and render the log in an attractive and usable way, and stash the results in a place that the html5browser testrunner can find them. I had that as cut-and-paste code, but I saw how the non-xhr yui tests have a convenience hookup, and thought that would be nice. I made a simple function that does the work. This shortens the tests by 10 or 15 lines, and makes it possible to change this code in the future in one place.

 - When working on yuixhr tests, you are working on Python fixtures and Javascript tests simultaneously. To make working with these tests interactively simpler, I made several changes.

   * The test JS has explicit headers to not cache.

   * The Python fixtures can optionally be reloaded. This is only allowed in interactive testing, and only if explicitly requested ("?reload=1"), and only when you load the HTML for the test. I have been burnt by reload in the past and vowed never to use it again, but the reload that I'm doing here I think is among the safer uses for it that I can imagine, and it is really convenient (ah, the seduction...). As long as the fixtures don't have (important) global state in the module, it should work fine. We clear out our own global state. The HTML has explicit headers not to cache so that this trigger will be honored, but because we are using a query string for the control the cache headers are really superfluous.

   * I added instructions and warnings on the test page so users can know how to work interactively.

 - Sometimes you want to have tests run within a particular Launchpad subdomain, or facet. This might happen if you want a test to interact with a page, for instance. You can now specify that the test should be run in a facet. This is honored in the automatic tests and in top-level +yuitest described above.

 - The installed config object was not correctly set when running tests. Notably, we were using the "testing" config as a basis rather than "testing-appserver". This makes a difference for the facet feature described above.

 - When running "make run-testapp", the developer had no help as to what to do next. I added simple instructions in the console output to go to a top-level +yuitest page. I created the corresponding page, which lists all the yui xhr tests it could find, and gives a link to them. It tries to honor the facet requested in the test_suite, and warns the user if it can't figure out the facet for one reason or another.

 - There was a bug that calling serverfixture.teardown if you had not run any setups would break. That's a problem because for some tests you have no setup, but you still want to run the test within a suite that has a standard serverfixture.teardown. Fixed.

 - I broke up the yuixhr render method into smaller methods, one per action. It seems nicer to me. My dispatch is a bit terse, but has plenty of Python precedent.

Lint has the following issues. I don't see that resolving the line length for the two Google URLs is valuable, so I don't intend to change that. The __traceback_info__ is intentional: it is for extra information in tracebacks, as rendered by zope.exception and lp.services.stacktrace.

./lib/lp/testing/yuixhr.py
     175: Line exceeds 78 characters.
     224: Line exceeds 78 characters.
     373: local variable '__traceback_info__' is assigned to but never used
     394: local variable '__traceback_info__' is assigned to but never used
     175: E501 line too long (100 characters)
     224: E501 line too long (100 characters)

That's it. Thanks.

Gary