Add order and direction parameters to listResources and getResourceUpdates

[pavog]

This PR adds the two parameters: order and direction.
These two parameters can be used with the actions: listResources and getResourceUpdates.

• order specifies the database field by which to sort, e.g., id, post_date, or download_count.
• direction specifies the sort order: asc for ascending (e.g., for IDs) or desc for descending (e.g., for dates such as post_date).

For the implementation, I took inspiration from the XenForo Resource Manager plugin. There, order options are also defined for each model using key-value pairs, as shown here, for example:

$orderOptions = [
  'id' => 'r.resource_id',
  'first_release' => 'r.resource_date',
  'last_update' => 'r.last_update',
  'download_count' => 'r.download_count',
];

By checking with array_key_exists() and retrieving the value from the array

$column = $order_options[$order];

we ensure that no SQL injection can occur via the order parameter.
If order is not specified or contains an invalid value, array_shift() is used to take the first entry from the order_options array. In both of these cases, it is the ID.

$column = array_shift($order_options);

For direction, it’s even simpler: The functions checks whether direction is desc

$dir = strtolower($direction) === 'desc' ? 'DESC' : 'ASC';

otherwise, it defaults to 'asc', so ascending order is the default.

Overall, this pull request adds the very useful feature to sort by IDs or dates (e.g., last_update). That would be very helpful for our purposes.

[jacobsandersen]

While I agree ordering is important to the API, I would suggest exposing specific order fields & directions rather than allowing user to select the field and direction themselves.

In your code you're basically already doing this - to be clear, what I'm suggesting is instead of 2 params make just one called something like sort and expose specific values like

id_asc, id_desc, etc and then use those to adjust the query internally. Decouples the API from the internal DB columns (though in the case of XF, it won't change since this is ancient XF).

Anyway, this is just a suggestion. Thoughts @md-5 ?

[md-5]

Unless I'm missing something isn't that really the same thing? Given that the first half will always be a key and the second half will always be asc or desc? I think this PR also already uses the API names (eg first_release) rather than the internal database columns.

Is there any other benefit of doing it as you suggest?

[jacobsandersen]

Just looked closer and, yeah, it's already fine. Disregard my suggestion.

[md-5]

Thanks. Do you have any comments/review on the code itself?