"Order by" in issues list and issues API hurts my brain

Summary

This is a meta-issue for several related bugs about the UX of ordering issues, on gitlab.com and the public API.

Sort order icons are ambiguous

This is a "descending order" icon. It is descending because it goes from big bars to small bars.

This is an "ascending order" icon. It is ascending because it goes from small bars to big bars. However, it looks like a descending staircase. This is the first thing that made by brain hurt, because I'm not sure what to think about this icon.

I propose that we incorporate some arrows that point downwards and upwards for descending and ascending order, respectively. Fontawesome has plenty of these

Sort order icon does not always reflect the sort order

Go to any issues list page where issues have weights
Sort by weight. Note the sort order icon.
Click on the sort order icon. The sort order is inverted, but the icon stays the same.
Take an ibuprofen, because your brain hurts.

This is the issue list when sorting by weight, ascending:

And this is the issue list when sorting by weight, descending:

What is the order of priority and label priorities?

Go to any issues list page where issues have different priorities or label priorities
Sort by priority or label priority.

The issues will be sorted correctly, and the sort order icon will be the "descending" one:

There are two ways to interpret priorities:

Higher-priority issues have a lower index, like P1 > P2 > P3 etc. So, issues are listed in ascending priority.
Higher-priority issues have a higher magnitude, and priority descends as you go down the list, so issues are listed in descending priority.

Which is it? I would assume that sorting issues by descending priority yields the correct ordering, because I'm sorting high-to-low and not by some number that the backend uses to keep track of priority.

REST API isn't clear on priority ordering

In gitlab-org/gitlab-ee!15225, @acroitor implemented sorting issues by priority, milestone due date, due date, popularity, label priority, manual ordering, and weight. Let's consider only priority and label priority.

With parameters order_by=priority&sort=asc, issues are returned by descending logical priority. That is, higher-priority issues are at the top.
With parameters order_by=priority&sort=desc, issues are returned by ascending logical priority. Sort of. Issues with low priority (e.g. due later) are first, followed by issues with high priority. Issues whose priority can't be calculated, because they are missing prioritized labels or milestones, still appear at the end. Note: you can't sort by low-to-high priority on gitlab.com.
With parameters order_by=priority, the API defaults to sort=desc, which may not be what users want. This does not mirror the behaviour on gitlab.com where sorting by priority automatically gives you higher priority first.

The same applies to order_by=label_priority.

Things to fix/decide

Consider an issue listing with high-priority issues at the top. Is this an ascending listing or descending listing?
- I propose that we call it descending priority. Descending order is the default order for things, so calling it descending allows us to display the correct ordering by default.
Sort order icon on gitlab.com when sorting by weight needs to be fixed.
Sort order icons should have some sort of arrow to better convey whether the order is ascending or descending.
Do we require users of the API to specify both order_by and sort in order to get the behaviour they want? Or do we:
- Have one default sort order for everything? (desc is the default currently)
- Change the default sort order for some parameters to reflect the users' expectations? (like the priority and label_priority circumstance)