Enable customization of minGasPrice value

[dpurhar27]

Problem

The minGasPrice value is leveraged in the new GasPriceMonitor module. It's used to filter out garbage gas price values returned from the ETH client's eth_gasPrice RPC call.

Read this tweet thread to understand how the evolving MEV environment on Ethereum plays a part in negatively affecting this functionality recently (and will continue too).

Currently, the value of minGasPrice is not customizable per node operator. It is hardcoded to 1 Gwei as seen below:

1. minGasPrice is set in the GasPriceMonitor constructor, passed in as a parameter)
2. Where the constructor of GasPriceMonitor is called here, passing in minGasPrice
3. With the value for minGasPrice being defined here
4. Which imports its value from the Geth namespace here
   
5. Where the value imported from the Geth namespace is defined here, as 1 Gwei

Setting minGasPrice to 1 Gwei may be substantial enough to solve the original issue, since it weeds out 0 and 1 wei gas prices. However, I see the role of minGasPrice expanding within the Livepeer client, as the GasPriceMonitor module expands. Hardcoding the value to 1 Gwei isn't nearly as effective.

See this comment thread #1906 to understand the new suggested role of GasPriceMonitor, where it will act as an appropriate filter for gasPrice values, which includes screening for too low gas prices.

Some Orchestrators/node operators would prefer more customization on there Livepeer client txns. Currently, txn gas prices default to the same across operators, based on what the ETH client (ie. Geth) suggests. This is susceptible to quick rises in gas prices which will cause pending/hanging txns, etc.

Example: Setting a custom higher minGasPrice to put priority on their broadcast txns such as rewardWithHint() which has a deadline, and must complete within each appropriate round in order to be valid and claim rewards.

Giving this optionality to node operators leads to more predictable business operations as well. If the Livepeer client screens gas prices it's using to broadcast txns with minGasPrice, an operator can evaluate "safe" gas prices to use where they're willing to spend the ETH required.

Example: Node operator sets their minGasPrice at 40 Gwei. Now they have peace of mind they're client will never try to broadcast a txn below 40 Gwei, and they have more control over how much risk and optimization they wish to partake in via txn costs/hanging txns, etc.

Also, note there's a maxGasPrice CLI argument, which sets precedent for such txn arguments to be customizable per node operator.

Solution

A potential solution is to add a minGasPrice CLI argument. It can follow the existing simple pattern of other valid CLI arguments such as maxGasPrice.

[yondonfu]

I can see the benefit in being able to customize a minimum gas price that is higher than the currently hardcoded value of 1 gwei. The proposed solution of adding a -minGasPrice CLI flag sounds good and I think would be relatively straightforward to implement once #1915 is merged - the value for -minGasPrice would replace the hardcoded 1 gwei value defined here.