refactor(core): Do not update firstUpdatePass in checkNoChanges mode

We don't want components to behave differently depending on whether check no changes.
This commit consolidates the remainder of the operations that should not
be done in checkNoChanges pass under a single `if` block where possible.

packages/core/src/render3/instructions/change_detection.ts

@@ -233,24 +233,23 @@ export function refreshView<T>(
         }
         incrementInitPhaseFlags(lView, InitPhaseState.AfterViewInitHooksToBeRun);
       }
-    }
-    if (tView.firstUpdatePass === true) {
-      // We need to make sure that we only flip the flag on successful `refreshView` only
-      // Don't do this in `finally` block.
-      // If we did this in `finally` block then an exception could block the execution of styling
-      // instructions which in turn would be unable to insert themselves into the styling linked
-      // list. The result of this would be that if the exception would not be throw on subsequent CD
-      // the styling would be unable to process it data and reflect to the DOM.
-      tView.firstUpdatePass = false;
-    }
 
-    // Do not reset the dirty state when running in check no changes mode. We don't want components
-    // to behave differently depending on whether check no changes is enabled or not. For example:
-    // Marking an OnPush component as dirty from within the `ngAfterViewInit` hook in order to
-    // refresh a `NgClass` binding should work. If we would reset the dirty state in the check
-    // no changes cycle, the component would be not be dirty for the next update pass. This would
-    // be different in production mode where the component dirty state is not reset.
-    if (!isInCheckNoChangesPass) {
+      if (tView.firstUpdatePass === true) {
+        // We need to make sure that we only flip the flag on successful `refreshView` only
+        // Don't do this in `finally` block.
+        // If we did this in `finally` block then an exception could block the execution of styling
+        // instructions which in turn would be unable to insert themselves into the styling linked
+        // list. The result of this would be that if the exception would not be throw on subsequent
+        // CD the styling would be unable to process it data and reflect to the DOM.
+        tView.firstUpdatePass = false;
+      }
+
+      // Do not reset the dirty state when running in check no changes mode. We don't want
+      // components to behave differently depending on whether check no changes is enabled or not.
+      // For example: Marking an OnPush component as dirty from within the `ngAfterViewInit` hook in
+      // order to refresh a `NgClass` binding should work. If we would reset the dirty state in the
+      // check no changes cycle, the component would be not be dirty for the next update pass. This
+      // would be different in production mode where the component dirty state is not reset.
       lView[FLAGS] &= ~(LViewFlags.Dirty | LViewFlags.FirstLViewPass);
     }
   } catch (e) {

packages/core/test/linker/query_integration_spec.ts

@@ -685,6 +685,7 @@ describe('Query API', () => {
          const template =
              '<auto-projecting #q><ng-template><div text="1"></div></ng-template></auto-projecting>';
          const view = createTestCmpAndDetectChanges(MyComp0, template);
+         view.detectChanges();
 
          const q = view.debugElement.children[0].references!['q'];
          expect(q.query.length).toBe(1);