ProductSeries:+index timeouts

Summary
=======

A quadratic-in-teams scaling function was added during the new subscriptions work. This regressed page performance on pages that trigger expose_user_administered_teams_to_js. Additionally this page itself is running the function multiple times due to this call stack:
lp.registry.browser.milestone:212(initialize)
expose_structural_subscription_data_to_js
expose_user_administered_teams_to_js

So each milestone view created is running the function and the function is slow (foo in a-list triggers quadratic lookup overhead). Fixing the repeated-invocations should provide significant amelioration.

Details
=======

Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.

Here is a few of the OOPs:

OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656

The oopses consistently show very high python time:

SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103

Things to look at:
 * per-driver / milestone owner code paths
 * get cody to generate a profile on https://qastaging.launchpad.net/++profile++show/bugsy/development

      15 0 7.6386 0.1779 lp.bugs.browser.structuralsubscription:431(expose_user_administered_teams_to_js)
      +64305 0 4.1135 0.7071 +canonical.database.sqlbase:240(__eq__)
        +795 0 0.7276 0.0290 +canonical.launchpad.webapp.publisher:465(canonical_url)
       +2130 0 1.3259 0.0115 +storm.sqlobject:522(__iter__)
        +795 0 0.9399 0.0064 +zope.traversing.browser.absoluteurl:34(absoluteURL)
        +795 0 0.0193 0.0031 +lp.registry.model.person:1619(title)
        +795 0 0.0011 0.0011 +<method 'append' of 'list' objects>
         +15 0 0.0026 0.0004 +lp.registry.model.person:2312(teams_participated_in)
         +15 0 0.0003 0.0003 +<method 'providedBy' of '_interface_coptimizations.SpecificationBase' objects>
         +15 0 0.2975 0.0001 +lp.services.propertycache:109(__get__)
         +30 0 0.0330 0.0001 +zope.site.hooks:93(adapter_hook)

drilling in:
  67563 0 4.1408 0.7228 canonical.database.sqlbase:240(__eq__)
     +190530 0 3.2106 1.3876 +storm.properties:51(__get__)
     +135126 0 0.2074 0.2074 +<zope.security._proxy.getObject>
      195453 0 3.3104 1.4272 storm.properties:51(__get__)
     +195453 0 1.0463 0.7612 +storm.properties:84(_get_column)
     +195395 0 0.4867 0.4779 +<method 'get' of 'storm.variables.Variable' objects>
     +195395 0 0.3503 0.3503 +<storm.cextensions.get_obj_info>

So death-by linear-lookups in expose_user_administered_teams_to_js