launchpadlib_for does weird, implicit things with interactions

[Graham Binns]

What happens:
When using launchpadlib_for in a test, the current interaction will get torn down by launchpadlib_for, which then creates a new interaction for the sake of its own code. This is then in turn torn down, leaving you with no interaction to work with. You then need to explicitly login() (or similar) again to do any further DB work. This can be demonstrated in the harness console:

>>> from lp.testing import launchpadlib_for
>>> person_1 = factory.makePerson()
>>> lp = launchpadlib_for("test", person_1)
>>> person_2 = factory.makePerson()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/graham/launchpad/lp-branches/hooky-hooky-bug-699719/lib/lp/testing/factory.py", line 335, in with_default_master_store
    return func(*args, **kw)
  File "/home/graham/launchpad/lp-branches/hooky-hooky-bug-699719/lib/lp/testing/factory.py", line 575, in makePerson
    person, email = getUtility(IPersonSet).createPersonAndEmail(
AttributeError: 'thread._local' object has no attribute 'interaction'

What should happen:
launchpadlib_for should be explicit about tearing down the existing interaction, perhaps throwing an error if an interaction is already present. It shouldn't be up to the (confused, new-at-this) developer to discover why they are having to add login() calls to make their tests pass.

[Robert Collins (lifeless)]

Perhaps it can restore the interaction afterwards?