`ApprovalController.clear` rejects all pending approvals and clears the state of the controller. This PR adds a "rejection error" parameter to the `clear` method and removes the default error. We decided that there is no reasonable default for this method, since `clear` may be called for a variety of different reasons.

We would like to introduce another fallback to how we estimate gas fees
in a future commit — namely, we want to use `eth_feeHistory` for
EIP-1559 networks if the usual API is down. To do this, the existing
code around gas fee estimates needs to be refactored. This is the first
in a two-part refactor, extracting the majority of the code in
`GasFeeController._fetchGasFeeEstimateData` to `gas-util`. In addition
to making room for more changes, this also allows us to test this code
in isolation from the polling code that already exists in
GasFeeController.

Note that I am using the term "calculations" to encompass the data that
`_fetchGasFeeEstimateData` returns. This is because `gasFeeEstimates` is
an intermediate value that can also be packaged with
`estimatedGasFeeTimeBounds`, so "estimates" could be confusing. Also, I
replaced "fetch" with "determine" as in the future we may be performing
calculations that APIs have done for us in the past ("fetch" seems like
a more low-level action).

If we are on an EIP-1559-supported network and the Metaswap API fails
for some reason, fall back to using `eth_feeHistory` to calculate gas
estimates (which the API uses anyway). This code is more or less taken
from the code for the API ([1]).

[1]: https://gitlab.com/ConsenSys/codefi/products/metaswap/gas-api/-/blob/eae6927b1a0c445e02cb3cba9e9e6b0f35857a12/src/eip1559/feeHistory.ts

The Metaswap API now includes a `networkCongestion` property when
requesting EIP-1559-compatible gas fee estimates. This value, which is a
number from 0 to 1, where 0 represents "not congested" and 1 represents
"extremely congested", can be used to communicate the status of the
network to users when they are sending transactions.

This commit ensures that GasFeeController includes `networkCongestion`
as part of the state it persists, no matter if using the Metaswap API to
obtain this information or falling back to `eth_feeHistory`.

This is a part of the EIP-1559 v2 work.

In future commits we will bring in more gas fee related data points from
the MetaSwap API. When we do this, we will have to implement fallbacks
for all of these data points. Every data point is different and will
require a different strategy and different testing. This commit breaks
up the existing fallback code so this is a lot easier to do.

Several new properties are now available from the `/suggestedGasFees`
endpoint in the MetaSwap API. This commit updates GasFeeController to
store these properties in state when polling for gas fee estimates and
implements fallback code for the underlying datapoints. This way we can
use these values to display different UI elements to users when they are
sending transactions.

The properties are:

* `historicalBaseFeeRange` — minimum and maximum values for the base
  fees over the past 200 blocks
* `baseFeeTrend` — an indicator for which direction the base fee is
  moving based on the current pending block vs. the latest block
* `latestPriorityFeeRange` — minimum and maximum values for the priority
  fees in the latest block
* `historicalPriorityFeeRange` — minimum and maximum values for priority
  fees over the past 200 blocks
* `priorityFeeTrend` — an indicator for which direction priority fees
  are moving based on the current pending block vs. the latest block

After integration-testing both the fallback and non-fallback code
responsible for pulling gas fee estimates, there were a few fixes
needed:

* `ethQuery.latestBlock()` was not being called correctly.
* For some datapoints, we need to pull the estimated base fee for the
  next block. This adds an `includeNextBlock` option to
  `fetchBlockFeeHistory` so that this is possible. It also splits the
  `FeeHistoryBlock` type into two types, because the next block won't
  have information about gas used ratios or priority fees (because there
  is no transaction data associated with the next block, as it doesn't
  exist).
* One of the allowed values for the `endBlock` argument to
  `fetchBlockFeeHistory` was "pending". This breaks
  `fetchBlockFeeHistory`, so this has been removed.
* Some of the datapoints were based on the wrong data, so this has been
  corrected as well.

…pdate logic (#665)

* add updateNestedCollectibleState to clean up redundant nested state update logic

* address feedback

* Add method to check and update collectible ownership state

* 23.0.0

* update changelog