[WIP] Custom element upgrades

Upgrade elements when a custom element is defined

BUG=594918

[dominicc (has gone to gerrit), 2016-05-16 07:57:33]

Not ready for review but FYI.

[yosin_UTC9, 2016-05-20 02:01:44]

On 2016/05/16 at 07:57:33, dominicc wrote:
> Not ready for review but FYI.

Rather than sorting collected elements, I would like to traverse when custom
element defined == On demand traversing

PROS of Sort
- O(E) where E is number of custom elements, E is smaller than N, number of
nodes

CONS of Sort/Collection
- Handle element removal, nodeWillBeRemoved, nodeChildrenWillBeRemoved,
didMoveTreeToNewDocument()
- Handle tree structure change
- document order comparison isn't cheap
- sorting code looks complex


PROS of On-Demand-Traverse:
- Simple code: traverse all nodes and enqueue a custom element upgrade reaction

CONS of On-Demand-Traverse:
- O(N) where N is number of nodes. 

For initial release, I would like to have a simple implementation.

[dominicc (has gone to gerrit), 2016-05-22 12:28:14]

On 2016/05/20 at 02:01:44, yosin wrote:
> On 2016/05/16 at 07:57:33, dominicc wrote:
> > Not ready for review but FYI.
> 
> Rather than sorting collected elements, I would like to traverse when custom
element defined == On demand traversing
> 
> PROS of Sort
> - O(E) where E is number of custom elements, E is smaller than N, number of
nodes

It's slightly more work than that, unfortunately, because we need to look at
ancestors and sometimes siblings of elements and ancestors.

> CONS of Sort/Collection
> - Handle element removal, nodeWillBeRemoved, nodeChildrenWillBeRemoved,
didMoveTreeToNewDocument()
> - Handle tree structure change

We already have to handle a bunch of these for callbacks like
connected/disconnected. In addition, we don't *have* to track these; we can
track creation and adoption and do the filtering when definitions are available.
That is why this uses weak members to track the candidates.

> - document order comparison isn't cheap

The sorter does not use document order comparison for that reason! It builds an
abbreviated copy of the tree and walks it.

> - sorting code looks complex

There are tests; are any missing? I was thinking this could be a candidate for
fuzzer testing too.

> PROS of On-Demand-Traverse:
> - Simple code: traverse all nodes and enqueue a custom element upgrade
reaction
> 
> CONS of On-Demand-Traverse:
> - O(N) where N is number of nodes. 

This could be a serious drawback. Because define only defines one kind of
element, if you define M elements in your app then this is ends up O(N*M). For
typical Polymer apps there are lots of different kinds of elements; some only
have one instance (like the top level foo-app); so if we start with a traversal
I think we will quickly be adding optimizations to it like counting the
instances of a given kind of element, etc. It's probably simpler to just sort
and be done with it.

> For initial release, I would like to have a simple implementation.

The sorter is an abstraction we can easily swap out; once we've implemented
everything else and there are some use cases let's get input on what the time
budget for defining elements is in those apps and measure the relative cost of a
simpler implementation. If it's not much more expensive on real apps and within
budget we can go with the simpler implementation.

I'm not interested in replacing the sorter before we have specific evidence.
There is a lot of other work to do.

[dominicc (has gone to gerrit), 2016-05-25 21:42:39]

Brief to-do list for this patch:

- Add tests: upgrade in document; context death in constructor; upgrade after
having been wrapped; poach elements by calling new before super
- Only use associateWrapper if there is no existing wrapper
- Use ScriptController or V8ScriptRunner to enter script; may need to plumb in
CallAsConstructor.
- Maybe implement the reaction queues, or maybe do that next