added 500ms delay before tooltip is closed

[HardikChoudhary24]

What does this PR do?

Fixes #6998

• Added 500ms delay before tooltip is closed.

Where should the reviewer start?

• In the stories

What testing has been done on this PR?

• Ran locally on storybook.

How should this be manually tested?

Do Jest tests follow these best practices?

• screen is used for querying.
• The correct query is used. (Refer to this list of queries)
• userEvent is used in place of fireEvent.
• asFragment() is used for snapshot testing.

Any background context you want to provide?

• Previously, the tooltip would close immediately when the mouse left.

What are the relevant issues?

• Tip - add slight delay before tooltip is closed #6998

Screenshots (if appropriate)

Do the grommet docs need to be updated?

Should this PR be mentioned in the release notes?

Is this change backwards compatible or is it a breaking change?

• yes

[taysea]

Thanks for the contribution! I'm thinking about if a timeout is the best approach for this or if there's any way to make the component smarter to know the mouse is in the region between the control and the tip.

For example, APG (an accessibility best practices group through WCAG) has been exploring a pattern that leverages CSS :after selector to have an invisible block for the region between the control and the tip: https://codepen.io/Moiety/pen/LaPvWy

I'm wondering if there's a way to explore a similar approach in Grommet. Right now, the space between the control and the tip is driven by a margin value in the theme. Is there anyway to use that value and incorporate that into the broader "click target" so that if the mouse is a) over the control, b) over the tip, or c) in the space between the tip and control, the tip will remain visible?