This move avoids the use of bisq.pricenode subpackages from a class
within that package, eliminating the cyclic package dependencies that
doing so causes.

This appears to have been copied and pasted from BisqAppMain in the
bisq-network/exchange repository.

bisq.price.node reads nicely, but 'app' packaging is the convention
elsewhere, is immediately intention-revealing, and sorts alphanumerically
to the top, helping the reader discover its nature as an entry point.

Casting to BtcFeesProvider in Pricenode is temporary.

Note that BitcoinFees should be made package-private at this point but
cannot because of the lingering cast in Pricenode.

See the previous commit, in which a similar approach was taken with
FeeEstimationProvider.

See previous two commits for context.

As in "Spot Exchange Rate", which is the price being dealt with in this
package. See https://www.investopedia.com/terms/s/spotexchangerate.asp.

This change normalize all existing exchange rate providers to conform to
this interface, including BitcoinAverage, which previously was the
special case, having getLocal and getGlobal methods instead of a single
request method. This is now no longer a special case, and simply treated
as two separate price providers that share a common base class.

…SYMBOL

We'll generalize back to the ExchangeRateProvider SPI when all
extractions are complete.

These lines will go away altogether soon enough.

Service layer returns maps of objects now, specific value types later.

This commit just demonstrates that this is possible. Fuller refactoring
for all provider types will come later, along with fully generalizing
and service loading them.

More work on the way to fully generalizing access to
ExchangeRateProviders by SPI while preserving the exact shape and
content of the exchange rate data itself..

Note that this change _adds_ a 'btcAverageLTs' while leaving
'btcAverageTs' in place in case anything is depending on this irregular
entry.

As required to access providers by SPI exclusively and not by special
type.

As opposed to repeating logic for each individual provider tracked by
its own field and with special implicit statement ordering rules that
must be explained by comments.

See previous commit's extraction of ExchangeRateProvider#addMetadata for
context.

Now produces log entries like the following:

    b.p.s.p.BitcoinAverage$Global: BTC/USD: 7469.27
    b.p.s.p.BitcoinAverage$Global: requestAndCache took 1038 ms.

    b.p.s.p.BitcoinAverage$Local: BTC/USD: 7471.75
    b.p.s.p.BitcoinAverage$Local: requestAndCache took 138 ms.

    b.p.s.p.CoinMarketCap: LTC/BTC: 0.018664
    b.p.s.p.CoinMarketCap: requestAndCache took 216 ms.

    b.p.s.p.Poloniex: LTC/BTC: 0.01869172
    b.p.s.p.Poloniex: requestAndCache took 260 ms.

And introduce a template method-style request/doRequest approach in
CachingExchangeRateProvider.

And document clearly that order of placement in the
META-INF provider-configuration determines the order of providers
in the List returned from ExchangeRateProvider#getOrder.

'ttl' (time to live) reveals the intention of this property more clearly
than requestIntervalMs, for it indeed represents how long exchange rate
data is supposed to live before being refreshed. Using an acronym here
vs spelling it out as ttl/TTL is quite well known, and pretty obvious in
the context of this explicitly-named caching component.

And document it a bit.

To simplify our BitcoinAverage provider implementation.

To simplify our CoinMarketCap provider implementation.

To simplify our Poloniex provider implementation.

I've gone back and forth on this style setting over time. As lambdas
have become more prevalent since Java 8, I think it's time to favor
4-space continuation indents over 8-space. I'll try it here in
bisq-pricenode for now, and we can see about standardizing on that
elsewhere later.

This is no longer necessary now that the data structure that stores this
information is no longer long-lived. It is recreated on each call to
getAllMarketData, which in turn returns the latest cached data from
underlying providers. This data is never older than the individual
providers' TTLs, so there is never 30-minute old data to purge, which is
what this method was for; it's just obsolete now.