bridge: re-introduce the max_read_size limit

[jelly]

This is a regression from our port of the bridge from C to Python. The C bridge had a limit and as fsread1 is not blocking implemented this prevents issues of accidentally reading /dev/zero or /dev/sda which will fill up ram endlessly.

---

See 7c7ab45 and DEFAULT_MAX_READ_SIZE

[martinpitt]

Nice, with test!

[jelly]

the revdeps failing is a legit issue (!)

Traceback (most recent call last):
  File "/source/test/check-application", line 1096, in testDownload
    self.waitDownloadFile("test.iso", 1500 * 1024 * 1024)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/source/test/check-application", line 92, in waitDownloadFile
    testlib.wait(filepath.exists, tries=120)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/source/test/common/testlib.py", line 2862, in wait
    raise Error(msg or "Condition did not become true.")
testlib.Error: Condition did not become true.

# Result testDownload (__main__.TestFiles.testDownload) failed

Hurray for reverse dependency testing and suggesting to download big files.

[martinpitt]

Indeed, yay for revdeps! Idea how to handle that.

[martinpitt]

Hmm, did the C bridge support any way of saying "indefinite"? Like "-1"? For download in files we have no way of limiting. But if we change files now to give -1, it will fail with the old bridge. So I think for the time being the only thing files can do is to set it to MAXINT64 for the time being. Then we add support for -1 here, and at some point we can change files accordingly. WDYT?

[jelly]

The C bridge never did, we never had big download support until cockpit-files and as files started with only supporting the Python bridge this just "worked".

Cockpit only had:

pkg/sosreport/sosreport.jsx:        max_read_size: 150 * 1024 * 1024,

Your proposal sounds good, it actually would unbreak our RHEL-8 testing was what I was thinking but it doesn't as we beiboot :-)