Enables users to add an array of FormControls to a FormArray using its existing .push() method, instead of pushing each new FormControl one by one triggering events along the way.

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.md#commit
• 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.io application / infrastructure changes
• Other... Please describe:

What is the current behavior?

FormArray .push() currently only accepts a single FormControl or FormGroup, manipulating a FormArray holding large datasets and using expensive validators is complicated by this behavior, as there is no easy way to refresh the dataset without breaking existing streams depending on its .valueChanges.

Issue Number: N/A

What is the new behavior?

FormArray .push() now accepts both a single FormControl or FormGroup, but also accepts an array of the same types. In case of an array, it will register all controls as expected and emit a single event after.

Does this PR introduce a breaking change?

• Yes
• No

Other information

Ran into this issue myself working at a client, where we could not easily manipulate a FormArray where we want to refresh a large dataset. Swapping it out for a new FormArray() seemed like the way, but this broke any existing streams subscribed to its original .valueChanges, making it difficult to keep everything in sync and reactive.

This solution at least makes it possible to manipulate a dataset within a FormArray as a new dataset, instead of having to iterate over all new controls. A possible expansion on this solution, and to promote immutability, could be to offer an additional method that also internally clears the existing dataset so a full replace would be possible.

Additionally, managed to run the entire test suite locally, except for //packages/zone.js/test:karma_jasmine_test_ci_chromium which seemed to not be able to connect to its ChromeHeadless browser and therefore fail. Hopefully the CI can run this test for me, but I'd still like to know what went wrong exactly. Short excerpt:

...
//packages/zone.js/test:test_node_error_lazy_policy             (cached) PASSED in 0.9s
//packages/zone.js/test:test_npm_package                        (cached) PASSED in 0.7s
//packages/zone.js/test/zone-spec/clock-tests:test_patched      (cached) PASSED in 0.5s
//packages/zone.js/test/zone-spec/clock-tests:test_unpatched    (cached) PASSED in 0.4s
//packages/zone.js/test:karma_jasmine_test_ci_chromium                   FAILED in 541.3s