ngOptions is setting select $dirty when options change and selected option is removed

[Narretz]

When the options change, and the currently selected option is removed because of that, we update the model and set it to the unknown / empty option. We do this by calling $setViewValue, which calls $setDirty. That means if the options change before the user has interacted with the form, the select is set to $dirty even though there was no user interaction.
We could do the following things:

1. Remember the $pristine state and restore it if was true
2. Don't use $setViewValue, as it's not really made for that purpose.

Bug was introduced here: 933591d

[petebacondarwin]

OK, so we can do the following:

        // Check to see if the value has changed due to the update to the options
        if (!ngModelCtrl.$isEmpty(previousValue)) {
          var nextValue = selectCtrl.readValue();
          if (ngOptions.trackBy ? !equals(previousValue, nextValue) : previousValue !== nextValue) {
            ngModelCtrl.$viewValue = nextValue;
            ngModelCtrl.$$parseAndValidate();
            ngModelCtrl.$render();
          }
        }

@Narretz do you think this will be acceptable?

[Narretz]

That looks good, but I think we also need to do ngModelCtrl.$$lastCommittedViewValue = nextValue, because that's what the parse pipeline and the validators use.

[Narretz]

We would still be losing the update to the empty status. Basically, we are just working around the problem. Imo we should be setting the model directly. Or enhance setViewValue so that we can skip the pristine setting in a logical way. Maybe by passing the trigger argument all the way to commitViewValue

[petebacondarwin]

Hmm, setting the model to null eh? That could work.

[Narretz]

I'm not sure if we have the right API for that. We'd need to access the model setter, but ngModel does not expose that. Since no-one else has found the bug, I'm also okay with pushing it back to post-1.4.8

[Narretz]

Not going to get fixed.