Add `borg list --sort-by=field`

[PhrozenByte]

/kind enhancement

Borg supports borg repo-list --sort-by=keys (Borg 2) resp. borg list --sort-by=keys (Borg 1, but for repo targets only) for ages now, but right now it's not possible to sort the output of archive listings (i.e. borg list with Borg 2 and archive targets with Borg 1). I'd like to suggest adding support for sorting archive contents with borg list.

borg list --sort-by=field should basically support most metadata stored by Borg. Field names should match the keys of borg list --format (which should also match that of borg diff --sort-by=field, if applicable; see #8998 and #9005). This at least includes path (obviously, also the default, see below), type (regular file, symlink, directory, …), mode (including special bits), user and uid, group and gid, size, mtime, ctime, atime, and birthtime. Sorting by ACLs, xattr, BSD flags, and hashes isn't reasonable IMHO.

It should be possible to add a > or < prefix to field names that controls order: > means descending order, < ascending order. Default (i.e. omitting the prefix) is ascending order.

The field value of --sort-by should be optional. If no field name is given, path is assumed. Without --sort-by the order should remain undefined (i.e. however the contents happen to be encountered in the archive). I'm undecided whether there should be an ultimate tie-breaker (I tend to "no" and to rather explicitly document order as undefined then).

Furthermore, it should be possible to pass a comma separated list to --sort-by. So, --sort-by="uid,>size,path" would first sort by item owner (ascending UID), then by item size (descending order), and lastly by path (ascending order).

As noted by Thomas in #9005 (comment) sorting might eat a lot of memory, simply due to the sheer number of metadata. There are many optimisation strategies to deal with this (from first collecting just the necessary data to choosing the right sorting algorithm to buffering on disk), but to keep things simple for now I'd suggest to simply warn users about a potentially heavy memory usage in the docs. Future improvements are possible without breaking anything, so there's no need for a perfect implementation from the start. Users can always resort to borg list --format … | sort if Borg's memory usage with borg list --sort-by is too high.

Reasoning:

I have sorted the output of borg list with borg list --format … | sort in the past, but it's no daily task to be honest (personally I usually use borg mount and check things via the mountpoint…). Since borg diff --sort-by=field was merged with #9005, adding --sort-by to borg list just feels natural and beneficial.

This is a nice-to-have feature, but definitely nothing that should block anything…