Price change causing orchestrator swaps

[eliteprox]

Describe the bug

There seems to be at least anecdotal evidence that adjusting price may be causing sessions to swap orchestrators. It is related to #2892 which returns an error during a segment if the price changes:

go-livepeer/server/segment_rpc.go

Lines 833 to 836 in 85bea86

	iPrice, err := common.RatPriceInfo(sess.InitialPrice)
	if err == nil && iPrice != nil && oPrice.Cmp(iPrice) == 1 {
	return fmt.Errorf("Orchestrator price has changed, Orchestrator price: %v, Orchestrator initial price: %v", oPrice, iPrice)
	}

Currently the broadcaster stores the initial price for the session in the BroadcastSession.InitialPrice field to validate against price changes every segment.

go-livepeer/server/rpc.go

Line 121 in 85bea86

InitialPrice *net.PriceInfo

The original approach is to ensure the broadcaster gets the original price for the stream by it's manifestid, but it seems some orchestrator info requests may not be within the context of a broadcast session, allowing new prices to slip through and cause unnecessary swapping.

To Reproduce
Steps to reproduce the behavior:

1. Run livepeer_cli on orchestrator in production with active streams
2. Use option 20:
   • eth addr = default
   • method = Wei
   • price per unit = any new price
   • pixels per unit = 1
3. Wait about 15 - 45 minutes and streams will drop, usually all of them.

Expected behavior
Pricing should remain the same for the entire session between broadcaster and orchestrator. Orchestrator price changes should only be used by new sessions.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Ubuntu Linux 22.04
• Version 0.7.3

Smartphone (please complete the following information):

Additional context
No errors seen on the orchestrator side. Broadcaster might be logging the price change based on the code linked above, but I have not been able to reproduce it in my own tests with a single B/O/T

[eliteprox]

This has been addressed in #2995. Closing issue