revert(chips): ng-required and ng-change

[Splaktar]

PR Checklist

Please check that your PR fulfills the following requirements:

• The commit message follows our guidelines
• 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
[ ] Infrastructure changes
[x] Other... Please describe: Reverts previous PRs that introduced regressions

What is the current behavior?

md-chips (standalone)
We have multi value supported with separator keys of enter, space and tab.
It works good when we have input like (url1 url2) and hit tab to move out of the field
It doesn't transform into chips when we have input like (url1 url2) and click anywhere outside of the field (this used to work before this sync)
After adding chips, if we remove the chips and retry with any input, it doesn't work. Somehow it makes the model as "undefined"

md-chips with md-autocomplete
We support multi value with separator comma, enter, space and tab.
It works good as long as we don't delete any chip. As soon as we delete the chip, nothing works.
We made sure model looks good even after deleting but somehow md-item-template doesn't get rendered (edited)

Issue Number:
#11217 and #11218

What is the new behavior?

md-add-on-blur works again and deleting chips does not break the ability to add or render new chips.

Does this PR introduce a breaking change?

[x] Yes
[ ] No

It removes two features that were introduced in 1.1.8. New PRs will need to be submitted to add them again with tests that cover these issues.

Other information

TBD

[fsmeier]

Would it not make more sense to wait 1-2 days before reverting? I it is still an improvement which needs a small bugfix and an additional test-case in my opinion.

[Splaktar]

@IMM0rtalis the reason for a quick revert is due to this code affecting Google production apps.

I am with you in hoping that this will only need a small/quick change to resolve and get back in. Unfortunately, I am still unable to reproduce these issues and I am working to get more reproduction information from the internal teams. After reproduction, we'll certainly work on adding test coverage.