fix(core): prevent destroyed views from being detached

[edusperoni]

A destroyed view will always remove itself after destruction, so it should never be allowed to be detached before that as doing so will break the destroy chain

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

When destroying a component, one might inadvertently try to remove the element from its ViewContainerRef. Doing so will break the destroy lifecycle hook as angular is unable to go back up the destroy tree.

Issue Number: N/A

What is the new behavior?

Attempting to detach/remove a node that's destroyed will fail to do so.

Does this PR introduce a breaking change?

• Yes
• No

Other information

I hit this when playing with CDK portals and doing:

const ref = portalOutlet.attach(portal);
ref.onDestroy(() => {
  portalOutlet.dispose();
});

portalOutlet will remove the item from the ViewContainerRef, which would stop destroying components with no error.

Maybe we could instead throw an error with a ngDevMode check instead?

[JeanMeche]

The change seems to be consistenly breaking as its shown by our local tests and ones in Google's code base.

[edusperoni]

@JeanMeche can you clarify where it breaks? It seems like the available tests all pass and I believe the behavior is undesired right now (breaking the destroy flow)

[JeanMeche]

It breaks some devtools and angular.dev tests. The timeouts are likely to be tied to some tests stuck on a whenStable() meaning we are breaking some other assumptions that currently caught in our core tests.