[BREAKINGCHANGE] remove dashbaord resource dependecy

[shahrokni]

Description

There is an ongoing effort to remove the core the dependency and replace them with what we have in the Spec.
This PR removes some of the dependencies (mostly DashboardResource, EphemeralDashboardResource) which have been already mentioned by @Nexucis

How does it replace the dependencies?

The PR introduces a new interface which represents an internal definition of any-Dashboard-Resource named DashboardMinimalResource.

• DashboardResource, EphemeralDashboardResource from EditDatasourcesButton.tsx
• DashboardResource, EphemeralDashboardResource from serializeDashboard.ts
• DashboardResource, EphemeralDashboardResource from LeaveDialog.tsx
• DashboardResource, EphemeralDashboardResource from common.ts
• DashboardResource, EphemeralDashboardResource from dashboard-provider-api.ts
• DashboardResource, EphemeralDashboardResource from DatasourceStoreProvider.tsx
• DashboardResource, EphemeralDashboardResource from useDashboard.tsx
• DashboardResource from dashboard-provider.tsx
• DashboardResource, EphemeralDashboardResource from DashboardApp.tsx
• Some important changes in dashboards/src/context/DashboardProvider/DashboardProvider.tsx

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• E2E tests are stable and unlikely to be flaky.
  See e2e docs for more details. Common issues include:
  • Is the data inconsistent? You need to mock API requests.
  • Does the time change? You need to use consistent time values or mock time utilities.
  • Does it have loading states? You need to wait for loading to complete.

[jgbernalp]

Do we have this type as part of the spec? I believe we are using the same metadata for all resources, so define a new one only for this resource might create discrepancies

[shahrokni]

We don't have them in the Spec as far as I know. And it seems they should not be part of the Spec as they are irrelevant there. At the moment the the original ones reside in the Core and should not be moved to the Spec. At least this is what I have understood. If we want to eventually drop the Core, we need to take care of the dependency in Shared.

A solution

What I can do is to flatten the DashboardMetaData and keep its filed in the main object (name and project). But, still not sure if this mitigate your concern. For the Kind however, there is nothing I can do. Kind has been used in the Shared, and has been exposed from the Shared. I am not sure what consequence we may encounter, if we drop it. > The main question is if removing the Kind would be a BREAKINGCHANGE which could be resolved.

[jgbernalp]

As discussed we can keep this intermediary type until we decide on a new location for it.

[jgbernalp]

To preserve backwards compatibility we should use

export type DashboardMetaData = { name: string; project: string, createdAt?: string, updatedAt?:string, version?: number};

[jgbernalp]

Do we need to duplicate the dashboardName here if its already in metadata?

[shahrokni]

Sorry missed