[Metrics v2] Add new /metric/:id and metric/:id/notebook pages

[nemanjaglumac]

This PR introduces two new routes.

1. /metric/:id that displays previously saved metric (which should open in the "chill mode")
2. /metric/:id/notebook that provides the option to switch to a notebook mode

Things to look out for

• UI should not offer to turn a metric into a model
• UI should not offer to preview SQL or convert a metric into a SQL question
• When one applies any change to the metric, its query should become "dirty", and the url should change to /question/query... indicating that we started a new ad-hoc question.

Notebook mode should not show metric's underlying query, but rather a new ad-hoc query started from the metric as a source:

Demo

https://www.loom.com/share/cbfe1f8fc3b045798cabf46ac0d812e4?sid=486b17fb-525d-4d37-b584-c8904490e980

Resolves #37368

[replay-io]

Status	In Progress ↗︎ 51 / 52
Commit	289319e
Results	⚠️ 3 Flaky ✅ 2274 Passed

[nemanjaglumac]

Self-review

There's one final thing at 5ab967c I can't currently solve.
When switching to a notebook view, the hash stays in the URL. This does not happen for models or questions so it must be a bug.

EDIT:
This should now be fixed by d017326.

[kamilmielnik]

URLs don't always work correctly for actions on /metric/:id page

[kamilmielnik]

1. Open up a metric
2. Select "Move" from "..." menu
3. Move it to another collection

❌ URL changes from /metric/:id-slug to /question/:id-slug

[nemanjaglumac]

I spent hours trying to figure this one out.
In the end, I'm not entirely sure if this is a bug in the existing implementation, or does it result from us hacking the question.type() before the real backend implementation.

What I managed to determine is that, upon moving a metric, getQuestion selector initially returns the question.type() "question". This is why the composeDataset doesn't apply.

[nemanjaglumac]

@kamilmielnik I finally realized what's going on. The hack for CRUD endpoints does not work for the PUT request. The payload does not have a type unless you're literally converting the type itself.

For example, this is the payload when moving a metric from one collection to another:

{
  "id": 82,
  "collection_id": null
}

Unless you have a different idea, we might have to ignore this and call it a limitation until backend implements the card.type for real.

[kamilmielnik]

Unless you have a different idea, we might have to ignore this and call it a limitation until backend implements the card.type for real.

All good, thanks for checking this ❤️

[kamilmielnik]

Works well 👍 🚢