fix(material/datepicker): change MatDateRangeInput input validation

[swseverance]

• Prevent MatStartDate._validatorOnChange() from being called when MatDateRangeInput's minDate input is updated with the same date.
• Prevent MatEndDate._validatorOnChange() from being called when MatDateRangeInput's maxDate input is updated with the same date.
• Resolves bug(mat-date-range-picker): Unable to pick a date when using functions with [min],[max] #19907

[crisbeto]

I'm not sure I follow how this fixes the original issue. Even if we validated again with the same inputs, the result should stay the same. The original report sounds like an bug that happens after change detection is triggered so wouldn't it break eventually if the user does something else that triggers it?

[swseverance]

@crisbeto I created a branch you can checkout if you'd like (bugfix/19907-example). It contains:

1. The bugfix
2. A replication of the stackblitz linked with the issue.

If you'd like to see that it works you can:

1. Checkout the branch
2. Run yarn dev-app
3. Go to "Examples"
4. Go to "Date range picker bugfix"

Here are my observations while debugging:

1. The (click) event was not firing on .mat-calendar-body-cell elements when they were clicked on.
2. getMin() and getMax() were invoked repeatedly, which led to _validatorOnChange() being called on
   the startInput and endInput. I think this triggered getMin() and getMax() to run again, leading
   to a cycle.
3. My fix prevents getMin() and getMax() from being repeatedly invoked, and allows the (click) event
   to fire on .mat-calendar-body-cell elements.

[crisbeto]

In the past we've closed similar issues where somebody causes change detection to run continuously by returning a different object every time, because even if we fixed it on our end, Angular is still doing extra work in the background and we're hiding the user's error.

[swseverance]

@crisbeto understood. I'll close the PR.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

[crisbeto]

Sorry for the churn here, we ended up changing our mind on this and decided to handle it after all since it breaks in a non-obvious way. I've submitted a separate PR since this one doesn't account for all cases #20362.