provide a generic enumerator that works on signatures, not input files

[ctb]

e.g. when running sourmash index on a database with 100,000 signatures, it would be nice to get a progress report 😂

can probably be added to load_file_as_signatures

[ctb]

it would be nice to be able to report % of total signatures reported, where that information is known - for SBTs and LCA DBs, it should be possible to know it as soon as the file is loaded.

[ctb]

the bit of this that wasn't fixed in #1083 is the actual index behavior - need to test it on challenging sourmash index and sourmash lca index data sets, with errors and stuff...

[ctb]

with manifests, this can be made much nicer now, too - we can indicate how many total signatures there are, even after (especially after?) selection criteria!

also I think this is quite relevant to UX principles around extremely large collections of signatures #1350

[ctb]

still need to big-brain this but in recent months we've moved towards just using manifests for everything possible. one outcome of this, along with the pattern matching code in #1871, is that we tend not to iterate slowly over many signatures, but rather iterate quickly over manifests.

In addition, there are reasons that I can't articulate at the moment 😆 where a lot of our search functionality doesn't lend itself to progress bars any more - like, how would that work on LCA and SBT databases anyway? will revisit next time I'm thinking clearly about it.

relevant - #1877 - where I'm thinking that the signature-focused loading/iteration code will actually go away.

[ctb]

In addition, there are reasons that I can't articulate at the moment 😆 where a lot of our search functionality doesn't lend itself to progress bars any more - like, how would that work on LCA and SBT databases anyway? will revisit next time I'm thinking clearly about it.

ok, yes, the problem is that SBTs and LCAs don't really have "progress" in searching as such. There's no simple way to estimate what fraction of the database has been searched.

I'm going to close this now, in favor of other issues - #1426 and #1877.