* truncate legend items

* avoid x ticks overlap

* Add E2E tests

* Allow adding models to dashboards

* Allow using models in native queries

* Fix last edit info vertical alignment

* Change picker's copy

* Handle undefiend question

Fixed by #15555.

Nested Queries Overhaul 2022: Split logic for determining appropriate table & column aliases out of SQL QP (#19384)

This is a safeguard against branch names with special chars which will be replaced by a "-" char

* big query schemas settings

* fix be specs

* Fix drill-through popover look for native datasets

* Enable some drills for fields from native queries

* Reproduce #19180

* Add `cancelQueryOnLeave` prop to NativeQueryEditor

* Don't cancel query when leaving model query editor

* Fix model icons in data picker

* Fix model icons in recent views

* Update the route from `dataset` to `model`

* Update unit tests

* Update e2e tests

* Fix failing e2e tests

* Update collection icon for collection permissions page

* Update collections icon for the serach filter page

* Update the collection icon in the "New" dropdown menu

We have a repo-wide CI run to check ESLint error anyway.
Meanwhile, for day-to-day development of static viz frontend, the main
webpack config is already equipped with ESLint check (along with hot
reload etc).

Trivial trends previously broke. Now they default to basically the ordinary single value viz.

Our email tests can be a bit brittle. Sometimes we assert the first
email in the email inbox is some password reset email, but a race makes
it such that its a "logged in from new ip" email. Othertimes, we might
assert that there are only emails to a particular user but maybe another
test might have triggered an email to another user.

We often might just want two predicates: did the user receive an email
with this subject, or did the user receive an email with this body.

This simply adds those.

It should be safe from races as it can handle emails to multiple users
and multiple emails to the same user.

* Comparison for goals depends on alert_above_goal and if progressbar.

This commit sets up the timeseries predicate and writes tests for what I think the correct behaviours should be:

timeseries, alert above -> (<= goal-value value)
 - (<= 5.9 6) true  -> alert sent
 - (<= 6 6)   true  -> alert sent
 - (<= 6.1 6) false -> alert not sent

progressbar, alert above -> (<= goal-value value)
 - (<= 5.9 6) true  -> alert sent
 - (<= 6 6)   true  -> alert sent
 - (<= 6.1 6) false -> alert not sent

timeseries, alert below -> (>= goal-value value)
 - (>= 6.1 6) true   -> alert sent
 - (>= 6 6)   true   -> alert sent. NOTE: this is to match prior behaviour, but I don't understand why it is this way?
 - (>= 5.9 6) faluse -> alert not sent

progressbar, alert below -> (> goal-value value)
 - (> 6.1 6) true   -> alert sent
 - (> 6 6)   false  -> alert not sent. NOTE: this is what should fix the bug (#10899)
 - (> 5.9 6) faluse -> alert not sent

I think there may be a cleaner way to write and present the tests, so the next commit(s) will address that.

* Simplified Tests for goal-met? predicate.

The goal-met predicate is tested directly with mock data to make the tests more readable.

The change to `metabase.pulse/goal-met?` fixes #10899 while preserving the goal-met behaviour for any non-progress
goal. The behaviour should now be as follows:

```
| Timeseries? | alert_above? | goal | val | goal-met? |
+-------------+--------------+------+-----+-----------+
|     f       |      t       |  5   |  4  |     f     |
|     f       |      t       |  5   |  5  |     t     |
|     f       |      t       |  5   |  6  |     t     |
|     f       |      f       |  5   |  4  |     t     |
|     f       |      f       |  5   |  5  |     f     | <--- this is new behaviour
|     f       |      f       |  5   |  6  |     f     |

|     t       |      t       |  5   |  4  |     f     |
|     t       |      t       |  5   |  5  |     t     |
|     t       |      t       |  5   |  6  |     t     |
|     t       |      f       |  5   |  4  |     t     |
|     t       |      f       |  5   |  5  |     t     |
|     t       |      f       |  5   |  6  |     f     |
```

Otherwise, alerts should be triggered as before.

* added issue number to test

* fixed alignment issue

* swapped goal and value around in comparison for readability

* Fixing nits

* Timeseries and progress bar now follow same logic

I asked for clarification about when alerts fire in #ama-product in Metabase's Slack. There was consensus around the
idea that 'reaches the goal' does generally imply 'meets the goal', so we can use the same comparators between
progress bar and timeseries goals now.

This simplifies the goal-met? function again because it's no longer necessary to check if the given data is a
timeseries goal.

* Adjusted text in goal line alert modal

* ran prettier

* Fix duplicate model tooltip

* Fix archive model title

* Fix edit model modal title

* Fix model verification title

* Fix add model to dashboard title

* Fix failing unit test

* Update model's archive message

* Separate builder from tester

* indentation error

* Final testing [ci nocache]

* [ci nocache]

Move bulk of dataset-id normalization logic into new private helper fn

Perform app DB update for db-details after dataset-id has been turned into inclusion filter

Add test to confirm that normalization only happens once

* Update SVG model illustration

* Update dataset -> model icons and their references

* Update icon names in collections