Simplify current store selection

[jhawthorn]

Previously we selected the current store by pretty hacky means. We took the value of either the SPREE_STORE HTTP header or the domain name, and then selected a store either matching that code or had that value contained anywhere in its url attribute. Failing to find these it falls back to the default store.

Using SPREE_STORE and finding by code is intended to be used with a reverse proxy like nginx, and is a good and powerful way to configure Solidus' multi domain. But it does require extra and very specific
configuration, and isn't overly suitable as a default.

Selecting by url which contains the (header or domain name) value is slow, surprising, and error-prone (think having example.com and ca.example.com).

This commit removes support for the SPREE_STORE header, and allows only one url per-store. Users needing this functionality can replicate it by implementing their own store selector class.

This commit also allows the store selector to perform only a single query to find the current store.

---

Before

SELECT  "spree_stores".* FROM "spree_stores" WHERE "spree_stores"."code" = ? LIMIT 1
SELECT  "spree_stores".* FROM "spree_stores" WHERE (url like '%localhost%') ORDER BY "spree_stores"."id" ASC LIMIT 1
SELECT  "spree_stores".* FROM "spree_stores" WHERE "spree_stores"."default" = ? ORDER BY "spree_stores"."id" ASC LIMIT 1

After

SELECT  "spree_stores".* FROM "spree_stores"
  WHERE ("spree_stores"."url" = ? OR "spree_stores"."default" = ?)
  ORDER BY "spree_stores"."default" ASC
  LIMIT 1

---

This is a breaking change, it doesn't have to be, but I think the new behaviour is enough of an improvement that it's worth breaking (with a very clear notice in the CHANGELOG).

I'd like to hear from users running multi-domain stores:

• Do you use this SPREE_STORE variable?
• Do you have multiple domains listed in any Store's url attribute (spree_multi_domain used to recommend them newline-separated). If so we may want to add better support for this.

Related to #1971, #2022

cc @kennyadsl

[tvdeyen]

👍

Maybe we could extract the previous behavior (mainly the header supporting one) into a second store finder class and still ship it with core, so existing stores can use the old one?

[kennyadsl]

This seems to be the best solution to me.

I didn't know multiple store urls could be set. If this feature is used can't we change the query using like (via by_url scope) and support multiline store urls?

[jhawthorn]

Maybe we could extract the previous behavior (mainly the header supporting one) into a second store finder class and still ship it with core, so existing stores can use the old one?

Absolutely! Do you think it's reasonable for us to use this as the new default? It should be an improvement for most stores.

I didn't know multiple store urls could be set. If this feature is used can't we change the query using like (via by_url scope) and support multiline store urls?

We could do that, and if we implement a "legacy" store selector class as @tvdeyen suggests, that is what it should do. That said, I'd rather remove that behaviour for this new implementation.

The most glaring issue with the current implementation is that it will incorrectly match ca.example.com for example.com (even if there is a separate example.com store defined). We could change the LIKE query to assume that the stores are newline separated WHERE CONCAT('\n', url, '\n') LIKE '\nexample.com\n', but that's getting really hacky. If multiple store urls are something many of our users need, we should introduce a separate table for it store_urls.