Rework InputFiles

[KnorpelSenf]

InputFile instances created from streams and iterators may not be reused. This PR adds a protection that will make the request fail if this is attempted. Previously, an empty or a partial file would be sent.

Also see this part of the docs on the issue: https://grammy.dev/advanced/transformers.html#use-cases-of-transformer-functions

Includes #87 and #94.

[wojpawlik]

Same problem as #28: I don't like putting getters in InputFile. The checks should be moved to Client. Perhaps the consumed field can even be eliminated: https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream/locked

[KnorpelSenf]

I don't like putting getters in InputFile.

Why not?

We can turn the getter into a function toIterator. That way, we could even eliminate all branching over data types in the client.

Perhaps the consumed field can even be eliminated: https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream/locked

I looked into this, but I don't want to convert everything back and forth just to save a flag.

[wojpawlik]

I don't like putting getters in InputFile.

Why not?

Complexity of file uploads should be contained in either Client or InputFile, not spread across both.

We can turn the getter into a function toIterator. That way, we could even eliminate all branching over data types in the client.

👍

[KnorpelSenf]

Agree it would not be spread out as it is now.

I would prefer to have it in InputFile because what is supported can diverge for both platforms.

[KnorpelSenf]

@wojpawlik what do you think about the SoC between InputFile and client now?

[KnorpelSenf]

@KnightNiwrem you're right that the Promise support is superfluous. I'd say we remove it again for now. We can introduce support for asynchronous generation of input data streams in a different PR.

[KnorpelSenf]

@wojpawlik @Loskir @KnightNiwrem can I merge?