fix(ckdoge): reject deposits below minimum amount

[gregorydemay]

Ensure that DOGE deposits will be ignored when their value is below a configurable minimum amount. This is needed to ensure that the minter does not control UTXOs whose value are below the dust threshold (0.01 DOGE). This was not a problem for ckBTC, which deducts a check_fee on the deposited UTXO value and whose value is above the Bitcoin dust threshold. In contrast, ckDOGE does not deduct a checker fee (check_fee is 0), but still requires deposited UTXOs to have sufficient value.

For that reason, the following changes were made to the ckBTC and ckDOGE minter:

1. Introduction of a new parameter deposit_btc_min_amount, which controls the minimum value a deposited UTXO must have to avoid being ignored.
2. The required minimum value of a deposited UTXO (which depends on the 2 parameters check_fee and deposit_btc_min_amount) is returned as part of the MinterInfo and displayed on the minter dashboard.

About CI_OVERRIDE_DIDC_CHECK: the following non-breaking changes were made to the Candid interface:

1. ckbtc_minter.did
   1. Adding a new optional field in InitArgs and UpgradeArgs
   2. Adding a new optional field in MinterInfo
2. ckdoge_minter.did: the ckDOGE minter is not yet live, so that any change here is by definition not breaking.

[THLO]

Nit: One would expect that a deposit of exactly deposit_btc_min_amount is permissible because the name suggests that it is the minimum accepted value.

[gregorydemay]

I don't get it, a deposit of exactly deposit_btc_min_amount would be accepted, since only if the utxo value is strictly less than the required minimum amount would it be ignored.

if utxo.value < deposit_btc_min_amount

[THLO]

What is the advantage of having a concrete parameter?
Why not simply have effective_deposit_min_btc_amount return max(MINTER_ADDRESS_P2WPKH_DUST_LIMIT, check_fee+1)?

[gregorydemay]

What is the advantage of having a concrete parameter?

1. There will be at least 2 different values used, e.g. MINTER_ADDRESS_P2WPKH_DUST_LIMIT for ckBTC and 1 DOGE for ckDOGE (an instance of CkBtcMinterState is also used by the ckDOGE minter).
2. We could use hard-coded constants that we put somewhere, e.g. CanisterRuntime, but to me it makes more sense to have it as init/upgrade args. It's easier to track what's going on in proposals and this also allows to have potentially different values between the different environments (ckStagingDOGE or ckTESTBTC)

[ninegua]

Thanks! LGTM

[mducroux]

Thanks for the PR! LGTM

[mducroux]

The doc does not make it clear if this is about the minimum amount in a single tx or in a single UTXO.