Test that handlers tolerate a non-empty unknown chunk prefix/suffix

[e3krisztian]

No description provided.

[qkaiser]

Given the current test output, we should investigate and open tickets for miscalculation on unaligned chunks in the following handlers:

• compression.compress
• compression.lzh
• executable.elf.elf32
• filesystem.romfs
• filesystem.yaffs.yaffs
• filesystem.yaffs.yaffs2
• filesystem.jffs2.jffs2_new
• filesystem.jffs2.jffs2_old

[e3krisztian]

There are a couple of problems with this PR:

The real stuff is here e.g.:

• https://github.com/IoT-Inspector/unblob/runs/6386032887?check_suite_focus=true

Some newer test runs fail due to timeout after 4m (more tests, and they are also of the slower kind).

[qkaiser]

The chunk calculation errors on filesystem handlers is due to calls to read_until_past, which is unbounded. We should read the exact padding size whenever possible.

• romfs: padding alignment is 1024 bytes, fixed in e872387
• JFFS2: padding size is the erase block size by default, but can be increased by setting it explicitly
• YAFFS: padding size is the page size by default, but can be increased by setting it explicitly

The chunk calculation error on compress and LZH comes from the fact that a random byte at the end of the compressed stream may be considered valid by the decompressor. Not sure if there is a way to overcome this.