Extra, or "reserve" keys up our sleeve

Assorted ideas of varying quality, for brainstorming. Some of the ideas are based on the idea that poor quality candidates are way better than wasting the same wall-clock duration on nothing.

As discussed recently, the very last batch of a GPU crack session (let's say the very last 18 words of a wordlist) will run very inefficiently on GPU with lots and lots of salts.

• One idea I had is having the auto-tune "keep a note" of the lowest GWS that is "pretty fine". In a saved output here we ended up with best GWS of 196608, but as you can see 12288 is also not too bad (and runs at virtually the same wall-clock duration as lower figures!). So for Single mode we could do the "oldest last rule catch-up" as soon as keys count hits 12288 or greater (or, depending on how you look at it, at (12288 - 511) or later given that #3489 is fixed, or perhaps even at any lower GWS that also runs at 45 ms, if you want to give priority to session resume). And for other modes, we'd want some "reserve candidates" to fill up to 12288.

• An other idea is to have all cracking modes push words that cracked a hash to a list (until eg. min_keys words are stored). Then, once we hit the last batch and need another 12270 candidates for utilizing the GPU reasonably, we simply take that list and run through rules (even if rules was otherwise not used in the session) to get the "missing" batch. Sort-of an in-built loopback mode.

• A third idea is to point to some exotic wordlist "up our sleeve" of better or worse quality and just use that one whenever we need a few thousands of new words. We might end up using the same "fill-up set" several times but anyway we do it is better than running with a GWS of 18 (the crypt_all() wall-clock duration is about the same anyway).

• We could specify "reserve rules" that we don't use unless we need to fill up last batch.

• Heck, we could even randomize candidates. Anything is better than nothing.

More ideas?

The issue names auto-tune, Single mode, reserve candidates or rules, and the crypt_all() path but no files or tests. Start by reviewing those areas and the referenced GPU batch behavior; the issue provides no single completion criterion, so one proposal would need to be selected and scoped before implementation.