multi: support config bitcoind fee estimate mode

[yyforyongyu]

This PR fixes issue #2990

Pull Request Checklist

• If this is your first time contributing, we recommend you read the Code
  Contribution Guidelines
• All changes are Go version 1.12 compliant
• The code being submitted is commented according to Code Documentation and Commenting
• For new code: Code is accompanied by tests which exercise both
  the positive and negative (error paths) conditions (if applicable)
• For bug fixes: Code is accompanied by new tests which trigger
  the bug being fixed to prevent regressions
• Any new logging statements use an appropriate subsystem and
  logging level
• Code has been formatted with go fmt
• Protobuf files (lnrpc/**/*.proto) have been formatted with
  make rpc-format and compiled with make rpc
• For code and documentation: lines are wrapped at 80 characters
  (the tab character should be counted as 8 characters, not 4, as some IDEs do
  per default)
• Running make check does not fail any tests
• Running go vet does not report any issues
• Running make lint does not report any new issues that did not
  already exist
• All commits build properly and pass tests. Only in exceptional
  cases it can be justifiable to violate this condition. In that case, the
  reason should be stated in the commit message.
• Commits have a logical structure according to Ideal Git Commit Structure

[wpaulino]

Thanks for the PR, looks pretty good!

[carlaKC]

Thanks for the PR! Just two style nits from me, non-blocking :)

[wpaulino]

Alternatively, we could also extend any RPCs that already require fee-related parameters with the estimate mode instead of having the config option. Though I think the two can still go together, as the config option will be used as the default, and you can express your preference differently through the RPC if necessary. Extending the RPCs would be out of scope for this PR of course. Thoughts @yyforyongyu?

[yyforyongyu]

Alternatively, we could also extend any RPCs that already require fee-related parameters with the estimate mode instead of having the config option. Though I think the two can still go together, as the config option will be used as the default, and you can express your preference differently through the RPC if necessary. Extending the RPCs would be out of scope for this PR of course. Thoughts @yyforyongyu?

Since it would require the user to restart lnd if changing the estimate mode is needed, yes, it would be better if we could also provide the option in related RPCs. Atm, I believe there are target_conf and sat_per_byte, maybe a third fee_mode can be added?

However, I think it won't be done without a drawback. Specifically, fee_mode can only be applied to bitcoind backend. The good part about putting it in config is that we can specify it under bitcoin.bitcoind, the downside is it needs to be restarted to change the value. The chainregistry tried pretty hard to use chainControl as an abstraction so that we won't need to worry about the different backends, adding a fee_mode in RPCs would certainly break it a bit, I think.

[wpaulino]

Specifically, fee_mode can only be applied to bitcoind backend. The good part about putting it in config is that we can specify it under bitcoin.bitcoind, the downside is it needs to be restarted to change the value.

Good point, we could return an error when using it with other backends. It's not something we need to worry about for this PR though.