v8.5.8

---------

Co-authored-by: ionitron <[email protected]>

Issue number: resolves #29094

---------

<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->

<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->

## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->

When assigning multiple selected dates that span different months, the
date time will not set the correct working parts and instead fallback to
the default date: May 28, 2021.

## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->

When opening the datetime with multiple dates selected, the calendar
will animate to the last value in the array of selected dates.

If the datetime is collapsed, body is not visible, is not a grid view or
the user has made a selection of a new date, the calendar will not
animate and instead will set the working parts to the current value
selected (latest/last value).

## Does this introduce a breaking change?

- [ ] Yes
- [x] No

<!--
  If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
  2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/docs/CONTRIBUTING.md#footer
for more information.
-->


## Other information

<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->

Internally we discussed setting the month view to the first value in the
array. Upon further investigation I determined this is not the expected
behavior. When a user interacts with multiple date selection, the most
recent selection (their active view) is the **last** value in the array.
Animating or updating the working parts to the first value in the array
would result in the calendar month jumping after every selection. Using
the last index of the array results in no odd jumps in the experience.
If a developer wishes to configure this behavior, they can change the
order of the values in the value assigned to the datetime (to cause a
specific month/date to be the initial view).

Dev build: `8.5.8-dev.11748388365.11ad9dfe`

---------

Co-authored-by: Maria Hutt <[email protected]>

…eds: investigation' label (#30424)

Issue number: internal

---------

<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->

<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->

## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
- Currently, `Ionitron` is closing issues when they have the `needs:
investigation` label.
- We might want to use the duplicate ticket as our source of truth since
a community member has made a
[suggestion](#30380 (comment))
that could fix it.

## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `ionic-issue-bot.yml` file was changed to stop closing issues that
have the `needs: investigation` label
- To prevent `Ionitron` from closing issues with the `needs:
investigation` label, we've added this label to the `exemptLabels` list
under the `stale`, `noReply`, and `noReproduction` sections.
- This tells the bot not to close issues with that label, even if they
meet the criteria for being stale or lacking a reply/reproduction.


## Does this introduce a breaking change?

- [ ] Yes
- [X] No

<!--
  If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
  2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/docs/CONTRIBUTING.md#footer
for more information.
-->


## Other information

<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
- _N.A._

---------

Co-authored-by: Brandy Smith <[email protected]>

)

Issue number: resolves several (listed at the bottom) + internal

---------

<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->

<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->

## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Currently, when expand to scroll is disabled in a sheet modal, we
duplicate the footer on drag and show a cloned version in the shadow DOM
instead of the original. This causes many issues (described in the Other
Information section), especially because often times the cloned version
of the footer would stick around instead of the original version, which
made any event listeners in the footer (and styling) broken by default
instead of only while dragging.

## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
We are now following [method 2 of the design
doc](https://github.com/ionic-team/ionic-framework-design-documents/blob/main/projects/ionic-framework/components/modal/0003-sheet-modal-scroll.md#approach-2-move-the-footer),
with minor deviation.

Now we try to eliminate the shaky behavior in the footer by setting the
footer to be absolutely positioned on the page and adding padding to the
bottom of the modal while dragging is happening to offset the missing
footer content. We are additionally performing some extra logic to swap
back when the modal is dragged below the height of the footer so that it
collapses correctly visually.

Note this is a minor variation in method two from the design doc because
I moved the footer to the body instead of to the parent modal. This is
because the parent modal will prevent anything not in its ion-page from
displaying, but it seems to work fine. As a side-effect of this, I had
to add an extra class and support for that class in a few areas so we
could identify footers that belonged to modals while they were moving
and apply applicable classes.

Additionally with this change I was able to remove all of the extra code
in the leave/enter animations because we no longer need to worry about
managing a clone of an element there. This allows me to contain all code
relating to behavior of the footer to `sheet.ts`.

## Does this introduce a breaking change?

- [ ] Yes
- [X] No

<!--
  If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
  2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/docs/CONTRIBUTING.md#footer
for more information.
-->


## Other information

This refactor in how the footer combats shakiness should resolve many
issues caused by the previous implementation, including the following:
- this change no longer has the footer being swapped out, effectively
breaking event listeners, which fixes #30315
- this change no longer has the footer being duplicated at all, which
fixes #30341
- this change no longer has the footer (sometimes) being moved to the
shadow DOM, which fixes #30312

**Current dev build**: `8.5.8-dev.11748530383.18b4e301`

---------

Co-authored-by: Israel de la Barrera <[email protected]>
Co-authored-by: Maria Hutt <[email protected]>
Co-authored-by: Brandy Smith <[email protected]>