fix(table): use default change detection strategy on table

[andrewseguin]

[Note: This change includes formatting changes as well as the actual code changes. The only change is that Default change detection strategy will be used instead of OnPush for table and row components.]

This resolves an issue with Ivy where change detection was not reflecting binding changes made to the row and cell templates in the component declaring the table.

In View Engine, change detection for a dynamically created view runs in two cases:

1. When the view in which it was inserted is checked
2. When the view in which it was declared is checked

As a result, if a dynamic view is inserted into an OnPush component, that view is not actually checked only "on push". It is also checked as often as its declaration view is checked (even if the insertion view is explicitly detached from change detection).

For this reason, marking MatTable as "OnPush" doesn't have much of an effect. It is built almost entirely of views that are declared elsewhere, so its change detection frequency is dependent on those declaration views. It also doesn't have any bindings inside its own view that would be protected by "OnPush", so marking it this way is effectively a noop and can be removed without performance regressions.

In Ivy, this change detection loophole has been closed, so declaration views can no longer de-optimize OnPush components. This means bindings inherited from declaration views aren't updated by default if MatTable is OnPush (the embedded view would need to be marked dirty explicitly).

To avoid breaking changes when we transition to Ivy, it makes more sense to perpetuate the current behavior by removing the "OnPush" marker. As delineated earlier, this has no impact on View Engine. For Ivy, it would ensure bindings inherited from the declaration view are still checked by default.

[kara]

LGTM

[kara]

caretaker: FYI have @jelbourn's verbal approval for this as well

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}