lib: more asyncification

[thoughtpolice]

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added/updated tests to cover my changes
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant. This includes,
  for example, commit descriptions, PR descriptions, and code comments.

[martinvonz]

Does it work to still call .map() but with an async closure and then wrap the whole think in try_join_all()? We've done that in lots of other places. It would mean that the commits are written concurrently if the backend supports it.

[ilyagr]

(Non-actionable, also mostly just wrong) I only glanced at this, but it sounds a bit similar to what I'm doing in #9087 maybe: create a stream of futures, and then convert it into a stream of outputs of these futures via .buffered.

I am not sure I whole-heatedly recommend it at this point, it does seem to add complexity.

Update: I think I misunderstood what Martin said as I started writing this. I'll leave it here, I think the analogy is interesting, but it's less actionable than Martin's comment.

Update 2: The approach of #9087 is not useful here, since you don't need streaming. You need to wait to get all the values before you can do anything with them.