Implement the gas price strategy: Sanitized providerRecommendedGasPrice

[bbenligiray]

We tended to use the gas price strategy providerRecommendedGasPrice in Airseeker. However, this caused some data feed updates with very large gas prices on Fantom. Upon realizing that many chains report a (correctly calculated) block base fee even if they don't support EIP1559 (such as Fantom), we came up with a new way to sanitize the provider recommended gas price as in

providerRecommendedGasPrice = recommendedGasPriceMultiplier * getGasPrice();
// Normally we would be done here
baseFee = getBlock().baseFee;
if (providerRecommendedGasPrice > baseFee * A) {
  return baseFee * B + C;
} else {
  return providerRecommendedGasPrice;
}

where example values are A=5, B=2, C=3 gwei.

Here's the reasoning: During normal operation, providerRecommendedGasPrice will always be less than 5 * baseFee, in which case we continue using providerRecommendedGasPrice as usual. providerRecommendedGasPrice is more than 5 * baseFee in two cases:

1. There is a momentary spike in gas prices, in which case ignoring that and using baseFee * 2 is perfectly fine (and baseFee * 2 is a rather aggressive gas price anyway). We don't use baseFee * 5 because providerRecommendedGasPrice being this high means providerRecommendedGasPrice is not to be trusted at all, and in a situation we don't know anything, baseFee * 5 is unreasonably large.
2. baseFee is almost zero because the blocks have been empty for a long duration (typical on testnets and deserted mainnets). This means that any gas price should be acceptable if enough of a tip is added (which is why we have the 3 gwei, but this may need to be specified per-chain).

To cover both of these cases, we use baseFee * 2 + 3 gwei.

Nodary tested this in production to patch the issue, and this works well on a variety of chains in that it both prevents Airseeker from using spiking gas prices and it also doesn't cause data feed updates to be lagged. It would be good to have this added as an official gas price strategy because, for example, QRNG Airnodes would also benefit a lot from this.

[bbenligiray]

If you're not aware, this is already implemented by @bdrhn9 in an Airseeker fork, it just needs to be transferred over to Airnode proper

[bdrhn9]

See thread: https://api3workspace.slack.com/archives/C02AYRX8D89/p1684140487018909
For visibility: @bbenligiray