Microsoft SQL Server requires a deterministic order when using `limit` (aka you have to provide `ORDER BY`). By default, in the MSSQL adapter, we inject a `ORDER BY [primary_key]` clause to achieve so, if not any `order` has been specified in the query.

This now leads to an issue in Solid Queue, where `concurrency_key` is selected and MSSQL complains that `id` is not in its `SELECT` clause.

I first looked into fixing this in the SQL adapter, but then found a test in `activerecord` itself (`test_pluck_and_distinct`) that orders first before calling `distinct`. So I would suggest to align Solid Queue here and order by `concurrency_key` prior to calling `distinct`.

I am aware that the existing code works with SQlite, MySQL and PostgreSQL as these do not require to pass an `ORDER BY` clause with `LIMIT`. I don't think this small addition will cause any troubles on the other DBMS systems.

…orkers (#547)

* Add test

* Unblock blocked job after failing claimed execution only in method called by supervisor

…rruptible

For all Rubies, and not just Ruby < 3.2.
This is looking like the most likely culprit of a memory leak pointed
out for multiple people on #330