E2E Test scenario: B<>O Streaming workflow

[leszko]

Create an E2E Test which covers the following scenario:

0. Start and register Orchestrator
1. Start Broadcaster
2. Fund Deposit/Reserve
3. Start a stream
4. Check if the stream was transcoded
5. Check that a ticket was received by Orchestrator
6. Redeem the ticket
7. Check that ticket was redeemed and ETH was paid
8. Withdraw Fees and check that ETH is in the O's acount

In this work, we should focus on a few aspects:

• We may either send the real video data or mock the video part. I suggest to send one real video segment via HTTP ingest
• It may be hard (or impossible) to tweak maxTicketEV and ticketEV, so that we're certain to receive a winning ticket, therefore we may need to set winProb directly in the code (white-box testing approach)
• If this scenario becomes too long, we can consider splitting it into a few scenarios (e.g. one for sending stream, one for redeeming ticket, one for withdrawing fees)

[yondonfu]

It may be hard (or impossible) to tweak maxTicketEV and ticketEV, so that we're certain to receive a winning ticket, therefore we may need to set winProb directly in the code (white-box testing approach).

If support for a -maxFaceValue flag is added in https://github.com/livepeer/go-livepeer/pull/2290 then we should be able to simulate a winning ticket just using CLI flags on B & O by doing the following:

• Let X be some value less than or equal to B's reserve allocation for O
  • Ex. If B's reserve = 100 and there is 1 O then the reserve allocation for that O is 100 so we'd want X <= 100
• Set -maxFaceValue X on O
• Set -ticketEV X on O
• Set -maxTicketEV 0 on B
• Set -depositMultiplier 1 on B

The first two CLI flags should result in a winProb = 100% because the face value of the ticket would be equal to the EV and the only winProb value that achieves that is 100%.

The last two CLI flags relax the restrictions on the faceValue and EV acceptable by B (typically those flags allow the B to restrict the values if needed).

[leszko]

@yondonfu Since we're not currently making any changes to that logic, I think it's less of a priority right now. What do you think about moving it to Icebox?

[yondonfu]

@leszko Sounds good.

Heads up that many of the items in the OP were covered in the e2e tests added in https://github.com/livepeer/go-livepeer/pull/2655. Still missing 5-8 though.