Backdate tickets by one round if the block hash for the current round is 0

[yondonfu]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Related to #2358

O sets the creationRound and creationRoundBlockHash to use for tickets here [1]. At the moment, the values used here are the last initialized round and the block hash for the last initialized round.

[1]

go-livepeer/pm/recipient.go

Line 205 in 786769b

CreationRound: r.tm.LastInitializedRound().Int64(),

Describe the solution you'd like
A clear and concise description of what you want to happen.

O could check if the block hash stored for the last initialized round is 0. If so, then O could "backdate" the ticket by using last initialized round - 1 for the creationRound and the block hash for the last initialized round - 1 for the creationRoundBlockHash.

The downside of this approach is that the validity period for a ticket becomes 1 round (basically the ticket is only valid until the start of the next round) instead of 2 since the ticket would be set to expire at last initialized round + 1 (last initialized round - 1 + 2 where 2 is the validity period for a ticket) and this also only helps if the block hash of the last initialized round - 1 is not zero - if you had two rounds in a row with zero block hashes this also breaks. The former case would only apply for the scenario where the block hash for the current round is 0 which we expect to be rare going forward and this change would primarily be to provide better behavior in the edge case where the block hash for the current round is 0 for some reason. Also worth noting that typically winning tickets are redeemed in the round that they are received.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.