feat: use less restrictive io type for file ingest

[alkasm]

Request's data param has type _Data | None as annotated, where _Data is defined as a union including SupportsRead[str | bytes] from typeshed. Since we don't need to parameterize by the string type (we already require binary file), I just copied over the impl from

class SupportsRead(Protocol[_T_co]):
    def read(self, length: int = ..., /) -> _T_co: ...

to

class HasBinaryRead(Protocol):
    def read(self, length: int = ..., /) -> bytes: ...

(and renamed to be in line with our other protocols)

[mariobuikhuizen]

Shouldn't the docstrings also be updated to reflect the new type?

[alkasm]

Shouldn't the docstrings also be updated to reflect the new type?

the docstrings just give an example of a binary file-like object, so I think it's fine

[drake-nominal]

Should we put this in a publicly-importable file? seems like something I could see users wanting to use in their types for code that interacts with nominal

[alkasm]

Should we put this in a publicly-importable file? seems like something I could see users wanting to use in their types for code that interacts with nominal

hmm. This is the double edged sword. If I ask for something more specific (e.g. BinaryIO), it's more restrictive than it really needs to be for consumers. On the other hand, if I minimize it down to the tiniest necessary bit (just read()) and then suddenly need one new method (e.g. seek()) it's now a breaking change. Blah, why is IO so annoying in python.

[varun-nominal]

this one still relevant?

[alkasm]

nah lets just leave it as-is