Support for the arbitrator v2

[jaybuidl]

Dependencies:

• feat: add arbitrum rinkeby support #254
• Deployment on Arbitrum Rinkeby gtcr-injected-uis#6
• Deployment to Arbitrum Rinkeby gtcr-subgraph#16
• Deployment on Arbitrum Rinkeby tcr#62

It's going to live in a separate v2 branch in the foreseeable future.

[greenlucid]

So, in the branch, I assume I don't need to support both kleros v1 and v2. What is necessary to support the new arbitrator?
Is this right?

1. Stop checking for appeals, remove the appeal logic altogether
2. disputeStatus calls (if exist), refactor out

[jaybuidl]

I don't need to support both kleros v1 and v2.

Yup, v2 only in this branch.

Stop checking for appeals, remove the appeal logic altogether.

We don't demo the appeals right now. But appeals can be requested on the DisputeKit. Which one? We can ask KlerosCore: which disputeKit for this disputeID and this round.

fundAppeal = async (disputeID, choice) => {
   const round = await KlerosCore.getNumberOfRounds(disputeID)
   (,,,,, disputeKitID) = await KlerosCore.getRoundInfo(disputeID, round)
   const disputeKit = await KlerosCore.disputeKitNodes(disputeKitID)
   disputeKit.fundAppeal(disputeID, choice)
}

(not tested)

disputeStatus

Not sure how it is used in Curate. If needed for display purposes or some logic, you could do

const dispute = await KlerosCore.disputes(arbitratorDisputeID)
switch(dispute.period) { 
   case KlerosCore.Period.appeal: { 
      // do DisputeStatus.Appealable stuffs here
      break; 
   } 
   case KlerosCore.Period.execution: { 
      // do DisputeStatus.Solved stuffs here
      break; 
   } 
   default: { 
      // do DisputeStatus.Waiting stuffs here
      break; 
   } 
}

[greenlucid]

#258

Will test if it works as intended later when an arbitrator frontend works to try it out.