refactor: do not keep track of membership registration order

[richard-ramos]

Description

Removes the ordering for the memberships according to discussion in waku-org/specs#34 (comment)

To expire a membership the client must keep track of the membership expiration dates, which can be done by using getCommitments(uint32 startIndex, uint32 endIndex) to retrieve the list of commitments, and expirationDate(uint256 idCommitment) to retrieve the expiration date of the commitments.

[alrevuelta]

Interesting and simple approach. Perhaps as part of the solution we should include a "reward" for the person calling eraseMemberships? Otherwise we risk that memberships are never expired?

[richard-ramos]

Could be an interesting incentive to add, but where would this reward come from? from the expired memberships?.

The way it's set right now is that memberships could be expired when we reach the maximum rate limit. The client would then have to find memberships that are expired whose sum of rate limits that will be free once they're expired is enough to allow a registration.

[fryorcraken]

Interesting and simple approach. Perhaps as part of the solution we should include a "reward" for the person calling eraseMemberships? Otherwise we risk that memberships are never expired?

I think for now, we can expect us (waku team) to run this when needed to help keeping it tidy.

Long term, there is an incentive for any project/application using this smart contract to call this so that their users can join in but it would make sense to have a small rewards indeed. E.g. allocating 1% of RLN fee for this reward.

[fryorcraken]

Offered some idea re error phrasing.

[richard-ramos]

@fryorcraken, all your suggestions and doubts should have been applied/answered!