Reducing complexity of implementation in order to be able to add Atlas text search token based pagination

[kbuma]

Summary

Major changes:

• remove parallelization of server requests
• re-implement handling of list criteria for parameters in endpoints that do not accept lists (this was tied into the parallelization code previously)
• re-implement handling of list criteria that is too large for a single request (this was tied into the parallelization code previously)

[tsmathis]

should favor .append(...) w/itertools.chain.from_iterable(...) at the end rather than repeated calls to .extend (especially since there is a loop later).

lines: 656, 701, 732, 806

[tsmathis]

Might be a ways off for being the minimum py version, but in 3.12 itertools introduced batched. I've used the approximate implementation from the docs before:

def batched(iterable, n, *, strict=False):
    # batched('ABCDEFG', 2) → AB CD EF G
    if n < 1:
        raise ValueError('n must be at least one')
    iterator = iter(iterable)
    while batch := tuple(islice(iterator, n)):
        if strict and len(batch) != n:
            raise ValueError('batched(): incomplete batch')
        yield batch

[tsmathis]

Not really much to say on my end, I am be curious though about the performance/execution time of this implementation vs. the parallel approach.

[esoteric-ephemera]

any(trace in str(e) for trace in ("422","414","Got 0 results"))

[esoteric-ephemera]

Should the batch size be chosen according to the limits we (may) impose on a Query? Or alternatively, should there be a check on the length of a batch after fixing the batch size? That way excessively long queries get rejected (e.g., I query for 1M task IDs, 100 batches would still give me an overly-long list of task IDs)