Move reusable API parts to a trait

[akumaigorodski]

This takes all reusable parts from Service trait and puts them into a more generally applicable AbstractService trait. The goal is to provide reusable parts for plugins which would establish API of their own (HC is such a plugin).

[akumaigorodski]

Materializer is not needed as of akka 2.6 (https://stackoverflow.com/questions/58768399/akka-stream-2-6-how-to-create-actormaterializer)

[codecov-io]

Codecov Report

Merging #1614 (930d20e) into master (b75f6c3) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1614      +/-   ##
==========================================
+ Coverage   85.92%   85.95%   +0.02%     
==========================================
  Files         151      151              
  Lines       11471    11471              
  Branches      505      505              
==========================================
+ Hits         9857     9860       +3     
+ Misses       1614     1611       -3     

Impacted Files	Coverage Δ
...clair/blockchain/bitcoind/rpc/BatchingClient.scala	86.36% <0.00%> (-13.64%)	⬇️
...cala/fr/acinq/eclair/payment/relay/NodeRelay.scala	93.70% <0.00%> (-1.58%)	⬇️
...nq/eclair/blockchain/electrum/ElectrumWallet.scala	80.51% <0.00%> (+0.25%)	⬆️
...q/eclair/blockchain/electrum/ElectrumWatcher.scala	76.98% <0.00%> (+2.38%)	⬆️
...clair/blockchain/electrum/ElectrumClientPool.scala	78.49% <0.00%> (+4.30%)	⬆️

[akumaigorodski]

What about this one, especially in light of #1640?

FWIW my opinion is current approach is good for these reasons:

1. API is a basic function which users expect to be packaged, not optional.
2. Once boilerplate code is factored out defining API becomes pretty straightforward both in core and plugins.
3. Having a common base interface feels better than letting each API-enabled plugin to build this completely from scratch.

[t-bast]

We have plans to heavily re-work the JSON API in the not-too-distant future, so I don't think we'll take in changes like the ones you propose until we've figured out where we want to go in more details.

Extending the API for custom nodes can very easily be done in a fork for now, it's a part that doesn't move much so it's easy to keep up-to-date with master.

[akumaigorodski]

Will keep it open to give it a chance to be considered still.

[t-bast]

Is this still necessary? I believe the changes we made to plugins recently enabled something similar to what this PR was doing.

[akumaigorodski]

Just forgot about this one, not relevant any more indeed.