Generally we should never be touching AR objects in migrations, this is
super risky as we may end up with invalid schema cache.
This code from 2013 did it unconditionally. This change amends it so:
1. We only load up schema if we have no choice
2. We flush the cache before and after
This makes this migration far less risky.
Fixes composer warnings when: a) mentioning groups ("By mentioning @group, you are about to notify x people...") and b) mentioning users in a PM ("You mentioned @user but they won`t be notified...")
Currently the theme is matched by name, which can be fragile when there are many themes with the same name. This functionality will be used by the next version of theme CLI.
If for some reason `Discourse.store.path_for` returns `nil`, the
forum would throw an error rather than returning 404.
Why would it be `nil`? One cause could be changing the type of
file store and having the `url` field no longer be relative.
Ember3 is more picky about having a container being destroyed and it's easier to cause exceptions, especially in tests.
This fix has been initially created for an exception occuring in tests when running discourse-code-review and discourse-polls tests at the same time. `getCurrentUser` method body was failing as the container was destroyed.
Original stacktrace:
```
"Error: Assertion Failed: expected container not to be destroyed
at new EmberError (ember:2929:31)
at assert (ember:1793:23)
at Container.lookup (ember:17736:64)
at PluginApi.getCurrentUser (discourse/lib/plugin-api:56:31)
at allowUser (javascripts/discourse/initializers/init-code-review:38:29)
at eval (javascripts/discourse/initializers/init-code-review:78:11)
at eval (select-kit/mixins/plugin-api:86:19)
at Array.forEach (<anonymous>)
at eval (select-kit/mixins/plugin-api:85:44)
at Array.forEach (<anonymous>)"
```
Somehow a plugin or some new Chrome bug is causing its heuristic to detect
our textarea for the composer as a target for address autocomplete
This is likely a chrome bug but this change is very safe regardless.
