Consider discarding items rewrittable storage

[greenlucid]

This is a hard call to make but I wanted to write it somewhere so that I can reflect on it later.
Currently, stake-curate has rewrittable item storage. This means that creating new items should be significantly cheaper if you're choosing used slots. More even so taking into account the saving is in L2 gas, since stake-curate will live in a rollup.

Recently, a decision involved allowing to write arbitrary data as bytes in the items (#17). In order to make it easier for other contracts to interface with stake-curate, the id of an item should be predictable.
This is not compatible with rewrittable storage.

we can either approach it as "not our problem" and keep the position of the items unpredictable, and force proxies to deal with that complexity. This will mean significantly cheaper item submissions in reused slots.
(It's not that hard to deal with that complexity, it's just annoying. proxies would have to deal with timestamps, etc. But they probably would need that anyway.)

Or we can dump the rewrittable storage idea entirely. This makes reading data onchain easier. It also simplifies a few methods. It also reduces some complexity off the user, and eliminates the need for the user to understand the slot system. Two routes:

• keep an itemCount. this will mean having an extra storage read and storage write per item creation. straightforward, but expensive. Simplifies a few things.
• allow all slots to be taken in any order. only rule is, a slot cannot be rewritten even if the item has gone through its lifecycle. This is cheaper but keeps some complexity (frontrunners could take a slot intentionally)

This is going to be a hard call so I'll take my time figuring out what better for the project

[greenlucid]

I decided against this

[greenlucid]

Revisiting this. There are upsides I missed:

• Incremental ids means there is no need to pass itemSlot as calldata. That makes it cheaper. acting on this incremental id costs ~5k extra L2 gas. this should be cheaper than the L1 gas from the calldata.
  • i did a small experiment, and for short term, the difference in L1 size is negligible. but it shall become larger as more lists are created.
• If only one item can ever live in an slot, there is no need to capture the block number when it's created. The evidence group id could simply be the itemSlot. this removes a function and simplifies things.
• code simplification (remove itemSlot emits, remove firstFreeSlot... etc)

another cool thing about this is, some lists would be able to keep the entire history of the item, without the current issue of

1. item gets created
2. item is challenged and removed
3. correct version of the item gets uploaded (thus, losing its reference to the previous one)

with this structure, instead, a list policy can enforce that the item has to be reclaimed. then, the history of the item (evidence thread + editions) wont be lost. this makes special sense for wiki use case.
reclaiming is not a feature yet, but it could be added.

[greenlucid]

Additionally, it could make sense to also stop making Dispute structs rewrittable. If so, then they should be set to zero to trigger refunds. But, this is not as important.
Should also be considered that allowing refunds to this will result in cheaper overflow attack for Disputes, whereas, in the rewrittable Dispute system, the number expresses the amount of Disputes that can be open simultaneously. (Of course, an attacker can create Disputes that will never finish, but still, it is fundamentally different)