QueryList.changes Observable is not closed on component destroy (ViewChildren, etc)

[shedar]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

QueryList.changes observable (for ViewChildren, ContentChildren and probably others) is not completed/closed on component destroy. So if there are subscriptions to a QueryList.changes - it should be explicitly unsubscribed to prevent memory leaks and performance degradation over time.

Expected behavior

When component is destroyed - it should implicitly close all QueryList.changes observables. Because operations is definitely complete for query list changes on component destroy stage.

Minimal reproduction of the problem with instructions

https://plnkr.co/edit/P6tpwaE5Nt2HZuyiSqWj?p=preview

1. open browser dev tools console
2. click "Toggle Child" button (it'll start logging state of the changes.closed (false) every second)
3. click "Toggle Child" again, so component is removed with ngIf, but ViewChildren.changes is not closed.

What is the motivation / use case for changing the behavior?

It's unintuitive that component-tracking observable is alive after component destruction and you have explicitly unsubscribe. It causes memory leaks, performance degradation in angular apps.

E.g. angular-material components have this issue, such as MdLineSetter, MdFormField and probably more.

Environment

Angular version: 4.3.5

Browser:
- [x] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[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.}