fix: sorting nested results by system time

[nguyenvukhang]

Bug is aptly described in #2243.

This PR aims to address this by delaying result sorting to after every match has been found.

[BurntSushi]

Nice work but yeah, there is a fair bit of work left here. The two big items:

1. It is a hard requirement that if --sort is not given, then there should be no additional overhead here. But in this PR, it looks like you always collect all of the paths before starting a search. Today, ripgrep will start searching well before it finishes directory traversal.
2. There are a number of places where errors are being swallowed. We can't do that.

I'm also not sure about moving sorting to the main functions. I think it's probably fine, although I was trying to keep the main functions as simple as I could. But if we are going to deal with sorting in main.rs, then I think it would be nice to add a short comment in the parallel searcher stating why it doesn't handle sorting. (Because if sorting is enabled, then parallel searching is disabled in args.rs.)

[nguyenvukhang]

1. It is a hard requirement that if --sort is not given, then there should be no additional overhead here. But in this PR, it looks like you always collect all of the paths before starting a search. Today, ripgrep will start searching well before it finishes directory traversal.

Yep. Fixed it. Top-level search() and files() functions will now specifically check if a sort that requires calls to stat is required.

The latest implementation using new functions continue_search() and continue_files() is a result of trying to coerce the types of the two possible states of preliminary search results:

1. uncollected and unconsumed iterator. (no sort)
2. collected, sorted, and re-made into an iterator.

I'd prefer to stick to having just one function for search and files each, though I'm not sure if that's possible.

2. There are a number of places where errors are being swallowed. We can't do that.

Agreed. I noticed that the previously reviewed code swallowed the Result<Walk> that args.walker()? emitted, and that has been fixed.

#2361 (comment) has also been addressed.

[BurntSushi]

You're all set. I already did the fixups needed to get this PR into shape. You can see it in #2555.

[nguyenvukhang]

I see. Thanks for patching up my tests and adding delays so the stat calls are correct.