Enqueue custom element reactions appropriately during upgrades

As pointed out in
#1297 (comment), the
setup introduced in #1309 allows custom element reactions to happen
during custom element constructors. This is unavoidable, but the spec
did not account for its consequences, leading to cases where a custom
element reaction would be called twice for the same attribute (or the
same element being connected). By moving these steps to the top of the
algorithm, we ensure that reactions are only enqueued for the state of
the world before the constructor runs, and that any reactions caused by
actions inside the constructor are then taken care of by the usual
mechanisms.

Closes #1297 again.

source

@@ -66414,13 +66414,31 @@ fetch(articleURL)
   <var>element</var>, run the following steps:</p>
 
   <ol>
+   <li><p>For each <var>attribute</var> in <var>element</var>'s <span>attribute list</span>, in
+   order, <span>enqueue a custom element callback reaction</span> with <var>element</var>, callback
+   name "<code data-x="">attributeChangedCallback</code>", and an argument list containing
+   <var>attribute</var>'s local name, null, <var>attribute</var>'s value, and <var>attribute</var>'s
+   namespace.</p></li>
+
+   <li><p>If <var>element</var> is currently <span>in a shadow-including document</span>, then
+   <span>enqueue a custom element callback reaction</span> with <var>element</var>, callback name
+   "<code data-x="">connectedCallback</code>", and an empty argument list.</p></li>
+
    <li><p>Add <var>element</var> to the end of <var>definition</var>'s <span
    data-x="concept-custom-element-definition-construction-stack">construction stack</span>.</p></li>
 
    <li><p>Let <var>C</var> be <var>definition</var>'s <span
    data-x="concept-custom-element-definition-constructor">constructor</span>.</p></li>
 
-   <li><p>Let <var>constructResult</var> be <span>Construct</span>(<var>C</var>).</p></li>
+   <li>
+    <p>Let <var>constructResult</var> be <span>Construct</span>(<var>C</var>).</p>
+
+    <p class="note">If <var>C</var> <a href="#custom-element-conformance">non-conformantly</a> uses
+    an API decorated with the <code data-x="CEReactions">[CEReactions]</code> extended attribute,
+    then the reactions enqueued at the beginning of this algorithm will execute during this step,
+    before <var>C</var> finishes and control returns to this algorithm. Otherwise, they will execute
+    after <var>C</var> and the rest of the upgrade process finishes.</p>
+   </li>
 
    <li>
     <p>Remove the last entry from the end of <var>definition</var>'s <span
@@ -66457,16 +66475,6 @@ fetch(articleURL)
 
    <li><p>Set <var>element</var>'s <span>custom element state</span> to "<code
    data-x="">custom</code>".</p></li>
-
-   <li><p>For each <var>attribute</var> in <var>element</var>'s <span>attribute list</span>, in
-   order, <span>enqueue a custom element callback reaction</span> with <var>element</var>, callback
-   name "<code data-x="">attributeChangedCallback</code>", and an argument list containing
-   <var>attribute</var>'s local name, null, <var>attribute</var>'s value, and <var>attribute</var>'s
-   namespace.</p></li>
-
-   <li><p>If <var>element</var> is currently <span>in a shadow-including document</span>, then
-   <span>enqueue a custom element callback reaction</span> with <var>element</var>, callback name
-   "<code data-x="">connectedCallback</code>", and an empty argument list.</p></li>
   </ol>
 
   <p>To <dfn data-x="concept-try-upgrade" data-export="">try to upgrade an element</dfn>, given as