refactor(input): remove $$parserName from email, url

[Narretz]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change?

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:

Since email and url don't use $parsers, we do not need to set the parserName.
This also reduces the number of times the valid / invalid classes are
set within for the input or possible parent forms.

This was discovered when fixing #14249. The additional class settings triggered
a cancellation of the structural animation. A general fix for this behavior has
landed as

[gkalpak]

For one, I believe this is a (tiny) Breaking Change, because previously we had ng-valid/invalid-url (or -email), while now we have ng-valid/invalid-parse.

If the problem is caused by trying to add/remove the same class multiple times (or trying to add and remove the same class) - once because of a validator and once because of the parser (which happens to have the same name as the validator), then we are not really solving it.

That same problem could happen, if the user chose to add a validator with the same name as $$parserName for example. (This affects all input types, not just email/url.)

I believe we could instead fix this inside processParseErrors(), by changing it to:

         if (!parserValid) {
           forEach(ctrl.$validators, function(v, name) {
-            setValidity(name, null);
+            if (name !== errorKey) setValidity(name, null);
           });
           forEach(ctrl.$asyncValidators, function(v, name) {
-            setValidity(name, null);
+            if (name !== errorKey) setValidity(name, null);
           });
         }
         // Set the parse error last, to prevent unsetting it, should a $validators key == parserName
         setValidity(errorKey, parserValid);

or better yet (to avoid the same error when $validators and $asyncValidators have the same key):

         if (!parserValid) {
+          Object.keys(ctrl.$validators || {}).
+            concat(Object.keys(ctrl.$asyncValidators || {})).
+            filter(function (key, idx, arr) { return (key !== errorKey) && (arr.indexOf(key) === idx); }).
+            forEach(function (key) { setValidity(key, null); }); 
-          forEach(ctrl.$validators, function(v, name) {
-            setValidity(name, null);
-          });
-          forEach(ctrl.$asyncValidators, function(v, name) {
-            setValidity(name, null);
-          });
         }
         // Set the parse error last, to prevent unsetting it, should a $validators key == parserName
         setValidity(errorKey, parserValid);

[Narretz]

With this change, we have now an additional ng-parse-valid class added to the element, but ng-(in)valid-email is on the element before and after the change.

I know that this doesn't fix all the cases where this can happen, I was just confused why url and email define the $$parserName at all. Maybe because they had a badInputChecker at some time (which uses a parser).

[gkalpak]

It's not only for our parsers; the same name will be set if the user adds their parsers to the input.
So, we might be breaking someone's code. (Note that if a parser returns undefined, then there will be no validation, thus no ng-invalid-email/url class (only ng-invalid-parse), which could mess up someone's styles.)

Just to be clear, there are two things I am saying here:

1. Removing the $$parserName makes sense (because if nothing else it is confusing to have the parser be named the same as a validator), but it is a breaking change.
   This means that (a) it should be documented as such and (b) it should not be backported to 1.5.x
2. Independently from (1), we should fix the underlying problem (which if I understand correctly happens when adding/removing the same class multiple times) as described in refactor(input): remove $$parserName from email, url #14292 (comment).
   This is not a breaking change and can/should be backported to 1.5.x

WDYT @Narretz ?

[Narretz]

I forgot about other parsers, yes that's right. I'm in favor of fixing this "right" with a BC in 1.6. I'd actually like to get rid of $$parserName and the while undefined === invalid thing, too, but I don't know if it's too big of a change at this point in 1.x