feat: removed claimed status from boost query

[ayushtom]

This PR makes the following changes -

• removes the claimed field from the get_boost query which returns the boost information based on id. Since there are mulltiple winners, we don't have a claimed value as such since there is no single winner.
• I also fix the pending_claims query to support multiple winners. Currrently the query didn't support querying the correct pending claims by a user.

Earlier approach -

• We used to match the winner from the boost but the assumption was that there is only one winner. So we used to match the boost winner with the claims which match in the boost_claims collection.

but now - the winner per boost is multiple, so the searching query doesn't function the same way.
To tackle this, i unwind in the first step to make it similar to how the query used to run and then check for equality in the following steps on the following fields - claim boost id to the matching boost id , winner (the winner address) to the claiming winner address and _cursor.to to null.

the flow for the product looks something like this -

1. User comes on the claim page
2. We fetch the boost information (check if user is winner)
3. We check in localstorage if boost is claimed(we save in localstorage in FE if the user has already claimed/opened the reward)
   4)if nothing on localstorage , then we check from pending claims(this takes data from indexer and finds if user has claimed anything from contract for this boost id)
4. Check from the information above
   a) if winner -> show a disabled/enabled claim button depending on steps 3 and 4
   b) if not winner -> show the better luck next time image

The checks we make for enabled and disabled claim button -

Enabled (these both are AND conditions)

• Step 3 -> there is nothing in localstorage of the user which shows that he has not claimed before
• Step 4 -> there is a pending claim with a boost id and it matches to the boost id which he/she is trying to claim

Disabled (these both are OR conditions)

• Step 3 -> local storage shows they have done this claim already
• Step 4 -> there are no pending claims from the indexer data