Ensure store-scoped values are selected before default

[mattdavenport]

We've encountered a bug in which a user created a category under a store scope with some values filled in (description, title, etc.). They then switched to the default scope, modifying other separate fields, and then switched back to the store scope to find the data they had inputted is gone. This occurred because the _getLoadAttributesSelect() query fetched the default values first upon going back to the store-scoped category page.

To reproduce:

1. The category is created on a store scope with some values added/selected.
2. Switch to default store scope view, adding value to category shop by attribute, saving the category.
3. Switch back to the store scope and some values are gone (description, page title, etc etc.).

This PR ensures store_id is sorted ASC to ensure the store-scoped values are also fetched properly.

[elidrissidev]

Rebased to bring the phpstan fix from last week.

If someone has got the time, please check if this is a regression in OM. Cause I tested briefly in a store running OM 19.4.14 and I couldn't reproduce it. I will check again later.

[elidrissidev]

Just confirmed that this bug is not happening in OM 19.4.14, there must have been a change in the following versions that introduced it.

[addison74]

@elidrissidev - Did you look in the history of the file starting with 1.9.14 to identify when the problem occurred? I looked quickly and didn't find anything.

[elidrissidev]

@addison74 Indeed I did. With the help of git bisect, I was able to find that this issue started from #1198. I would prefer that the fix in this PR be updated, cause it seems like a workaround.

[elidrissidev]

Hey @mattdavenport, are you interested in updating this PR with a proper fix now that we found the origin of this issue?

[mattdavenport]

@elidrissidev I unfortunately won't have time for this in the near-term. If you would like to propose a fix or keep this PR open until I'm able to return to it that's fine as well. Thanks for looking into this btw!

[fballiano]

@elidrissidev what do you think we should do with this PR? Also, I can't rebase it to main :-(

[elidrissidev]

Could be closed and converted into an issue until there's a proper fix for it, already was on my list for some time just can't figure it out.

[fballiano]

I think the "order by" is maybe not the cleanest solution ever but I don't see it as an ugly workaround, it's effective and quite easy and I'd probably have that instead of the bug :-)

@mattdavenport would you be able to rebase this PR to the "main" branch? sadly I can't do it for you.

[mattdavenport]

@fballiano Agreed on the implementation. Better than nothing I suppose :). I should have some time to rebase this tomorrow so I will take a look. Thanks!

[mattdavenport]

@fballiano Should be good now. Sorry I didn't notice this was easily doable via Github UI 😄.

[fballiano]

@mattdavenport I still see it on 1.9.4.x, I see your force push but I still can't change the branch in the PR because it generated 5000+ modified files :-(

[fballiano]

tested