fix: fr32: Make UnpadReader be a correct Reader

[magik6k]

Related Issues

Fixes #9324

Proposed Changes

The fr32 unpad reader currently requires that the output is power-of-two-unpadded size, which is an extremely sketchy assumption and seems to cause lots of pain in retrievals.

There is already quite a lot of code in piece-provider which ensures that reads are initialized at correct offsets (multiple of 127-unpadded-bytes), but the read sizes are only ensured by the fact that the output reader is wrapped in a bufio.Reader, which won't always buffer writes with the required size, leading to hard to debug panics.

This PR aims to make the UnpadReader behave more like any normal reader, removing a giant footgun in the retrieval code.

Additional Info

I realize that this code should probably eventually be external to lotus, but right now both boost and curio depend on this for decoding fr32 data. Should be extracted but let's fix the panics first.

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[rjan90]

Looks like there are a couple of lint errors related to not checking the error return value of the rand.Read() that needs to be addressed.

[rvagg]

Would be good to also address @ribasushi's findings in https://filecoinproject.slack.com/archives/C06GD1SS56Y/p1727046562422669 - set numcpus low enough and this reliably borks; although it's the same before and after this patch. Something odd going on when you get below 8 CPUs.