Sort direction for selection depth wrong when doing best-hold selection

[Galen Charlton]

Due to a five-character error in commit 6b53189a9 that implemented custom best-hold selection sort orders, the sorting direction for the hold selection depth is ascending, not descending.

This is a mistake: the intention is that holds that have a more limited selection depth (i.e., have a higher value for action.hold_request.selection_depth) be preferred over ones that have a broader selection depth (i.e., have a lower value for the column). The reasoning is that holds that have a broader depth also presumably have overall more copies that could fill the hold. This is particularly applicable when soft boundaries are being used.

[Mike Rylander (mrylander)]

I've pushed a branch to address this by inverting the selection_depth sort order in the data used to calculate the sort order for holds to test against a copy in hand:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-2023338-bhsso-selection_depth-fix

[Terran McCanna (tmccanna)]

This is difficult to test, but the fix makes sense to me and is likely the fix for some hold order weirdness we have seen. After discussing it on the DEV list and with the 3.12 release team, I'm happy to commit it.