Proofs should be required from the moment a slot is filled,
not from the moment a request is submitted.
This reverts commit f224cb8eda74a166f0bb3020032026a8dec26466.
Rationale: in practice, a ProofId was always a slot id, and
an EndId was always a request id. Now that the definitons
of SlotId and RequestId are separated from the Marketplace,
we can import and use them.
- Marketplace tests for requestsForHost, and additional tests for myRequests and mySlots
- Added Utils lib with tests
- Added additional Bytes32AddressSetMap.keys expectations
Add `Bytes32AddressSetMap` which maps addresses to a requestId. This is used in `Marketplace.activeRequestsForHost`, where all addresses for a particular requestId are listed. This can then be used to iterate and list out the actives requests for a particular address in a view function only. This allows for all addresses for a request to be cleared in situations such as when a request fails or is cancelled.
Reinstate the index mapping for `activeSlots`, however with a modified data structure. The main difference comes from a change in `mySlots`: it now requires a `RequestId` as a parameter (which can be obtained using `myRequests`. This allowed for the `activeSlots` mapping to be keyed on `RequestId`, which gives a mapping of `ActiveSlotId => EnumerableSet.Bytes32`. `ActiveSlotId` is a keccak hash of `address + activeSlotIdx`, which not only allows retrieval of all active slot ids per request, but also allows clearing of all active slot ids for a request by incrementing the `activeSlotIdx`.
```
requestId => [ keccak(address + activeSlotIdx) => EnumerableSet.Bytes32 ]
```
Instead, iterate all active slots and remove them individually, only if they are part of a specific request. This is only for the case of request failure.
Allow for clearing of active slots by host, by incrementing an mapping index. The new index points to a fresh instance of EnumerableSet, effectively wiping it clean.
There may be cases where the the request end is not accurate as the state of the request hasn’t yet been updated. For example, when a request is cancelled, the request end would not have been updated to be in the past, and would still be set for the end of the request (which could be in the future).
