perf: stamp issuer write coalescing

[martinconic]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

Resolves #4884

This PR addresses extreme LevelDB I/O bottlenecks and CPU serialization overhead encountered during massive high-frequency chunk uploads.

The Problem

Under a load of hundreds of thousands of concurrent chunks, the node suffered from performance degradation across two distinct vectors:

1. LevelDB Put Lock Saturation: Writing a stamp item for every chunk requires locking LevelDB. Under 1M concurrent pushsyncs, this sequentially locked the disk queue, choking disk writes up to >100MB/s and stalling the networking routines for >140 seconds cumulatively on CPU profiles.
2. JSON Deserialization Overhead: Updating peer and surplus balances required fetching extensive math objects from the statestore. The unoptimized branch utilized JSON unmarshal to decode these values from ASCII text. Under heavy load, the CPU burned >20 seconds of pure flat execution time just parsing strings.

The Solution

1. StamperStoreCache (Debounced Async Writes)
   • Wrapped the Stamper Store in a highly concurrent memory cache.
   • Network routines now instantly write payloads to a thread-safe map in RAM.
   • A background flush loop sweeps the map every 5 seconds, writing thousands of items into LevelDB in a single, atomic batch. Disk churn drops massively, and the master process is completely freed from I/O wait times.
2. Binary BigInt Encoding
   • Implemented binary marshaling natively onto the central BigInt struct.
   • Refactored all accounting database getters/setters to utilize raw binary memory allocations instead of strings.
   • Included a silent fallback mechanism: the binary unmarshaler seamlessly parses older JSON-encoded database values so upgrades require no explicit database migration.

[acud]

@martinconic thanks for this. I have some comments:

1. this PR states it is about stamperstore disk usage, but modifies also the accounting package. those are different problems and it would be good to be a bit more meticulous about the scope of PRs
2. there is no need to reinvent serialization for the big.Int package. it already supports multiple formats out of the box, please see the standard library documentation
3. there is a shutdown logic added to the stamp persistence store. i am not sure whether this is needed on a package level or if we could have this on the application level. if we have components implementing this themselves we already are starting to duplicate logic. it is something that the application should provide. see the .DIRTY file as it touches this topic too. perhaps something similar is needed (or reusing of the same thing).
4. bucket recovery logs in Debug (why not Error?) and swallows the error, the actual meaning of this is the future uploads of the user will override previously uploaded data. this is pretty severe.
5. persisting the stamp buckets (in the loop with the ticket) emits warning, not error
6. closing of the postage service reads off the channel it is closing, which should return immediately, not sure why it is needed

[acud]

i'm not sure why this should be here. why can all this code live inside the stamper store init and close methods?

[acud]

ditto. Close is called in L1453 anyway, why cant this be executed as part of that method as the last thing done? and in any case, if you really wanna keep it outside, this block should execute after L1453 no? since you still didn't close it, how do you know to say it was shutdown cleanly? also, even if it did you wouldn't know, because the err returned from Close is not available in this scope

[acud]

why is it dirty all of a sudden? it was just restored from disk, so it is not dirty per-se (since dirty means there are writes which aren't flushed yet)