Add connectivity status to Kubernetes Agents listing

What does this MR do?

This MR adds two columns to the GitLab Kubernetes Agent table:

1. Connection status
2. Last contact date

Both values are processing from the most recent token last connection date (based on lastUsedAt field of the clusterAgents -> tokens). There are 3 options for the status:

• unused in case no token was connected
• inactive in case the token last connection time is more than 8 minutes ago
• active in case the token last connection time is less than 8 minutes ago

There's a tooltip showing the last connection relative time for the active status. There's a popover with some troubleshooting information for other statuses.

Last contact date shows the relative date of the last connection and has a tooltip with the absolute date.

Screenshots or Screencasts (strongly suggested)

The new columns in the table

The popover for the unused state

The popover for the inactive state

The tooltip for the active state

The tooltip for the connection date

How to setup and validate locally (strongly suggested)

1. Follow the documentation guide and add the GitLab Kubernetes Agent from the UI on Infrastructure -> Kubernetes Clusters -> GitLab Agent managed clusters page
2. To create an agent in the unused state don't use the generated token
3. To create an agent in the active state follow the documentation.
4. To create an agent in the inactive state you can install the Agent into the cluster and then delete it using kubectl delete -n gitlab-kubernetes-agent -f ./resources.yml command

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• [-] I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Related to #323058 (closed)