* Update kamon and kanela-agent
Previous version was not compatible with JDK21, see https://github.com/kamon-io/kanela/issues/150.
* Add and configure maven wrapper to use maven 3.9.9
This will make it easier to control which version of maven is used to build eclair, which in turns makes deterministic builds easier, as well as using recent compiler options (to target newer JDKs for example).
For example, even recent versions of Github runner images use an old version of maven and there is no easy way to upgrade.
* Update Dockerfile
We now use multiarch (amd64/arm64) base images.
* Run CI tests with JDK21
* Update doc to recommend Adoptium OpenJDK21
* Target Java 21
Eclair now targets Java 21 and will require a compatible Java Runtime Environment.
It will no longer work on JRE 11 and JRE 17.
* Update CI test with latest bitcoin core (switch from autotools to cmake)
bitcoin core now uses cmake instead of autotools.
CI test is triggered by a cron job but can now also be triggered manually.
- link to plugins repository
- remove android mention for eclair
- update other implementations (renamed)
- update docker CI action versions
- missing eclair-cli APIs in help
* Remove close() in db interfaces
It shouldn't be the responsibility of individual db classes to close
the underlying db connection because they typically share the same db
instance (postgres) or db files (sqlite). Closing should be handled in
the `Databases` level (which is already the case for postgres.
For sqlite, closing was only useful for mobile apps, which now use
lightning-kmp.
Also removed `DbFeeProvider`, which was only used by mobile apps.
* increase github ci build time 20min->30min
We should regularly run against bitcoind master, to detect if a change to
bitcoind is affecting us.
This will let us detect changes that may break lightning before bitcoind
releases them, giving us a chance to rectify it.
We really don't want to run this workflow for every pull request or every
merge to master, we instead run it twice per week, which should give
us enough time to detect dangerous changes.
The default is 360 minutes which is very long.
Our builds are usually around 10 minutes, so 20 minutes is a good value
to prevent overbilling builds that create infinite loops.
These tests have been flaky because external APIs tend to be down or throttle
our calls. and we don't want our test suite to fail because of that.
In practice it's enough if developers run these tests locally once in a while.
