getLedgerEntries: optionally use high-performance Core server

[Shaptic]

What

This introduces STELLAR_CAPTIVE_CORE_HTTP_QUERY_PORT, enabling a high-performance HTTP server on the Captive Core subprocess for fetching ledger entries.

This new endpoint is plumbed all the way through the getLedgerEntries handler, removing those database queries entirely.

This also updates the stellar/go monorepo reference and its cascading dependencies.

If STELLAR_CAPTIVE_CORE_HTTP_QUERY_PORT is set to 0 (the default value) RPC will use it's old and proven DB implementation of getLedgerEntries instead of querying Core.

Why

With CAP-66 arriving in Protocol 23 and its high-performance /getledgerentry endpoint (whose client was implemented in stellar/go#5542), we don't need to store ledger entries in RPC anymore.

Today, we still need to provide snapshots to the simulation library, but tomorrow (in the opaque sense) we won't need to, so this is part of the transition work.

Related: #269.

Known limitations

TODO:

• Ensure that the correct captive core configuration is generated to enable the server, per details in Add state archival getledgerentry endpoint stellar-core#4623.
• Integration testing

[Shaptic]

@2opremio this should probably target a new feature branch e.g. protocol-23 🙏

[Shaptic]

Looks really solid! Coupla questions but otherwise pretty sure this can get a ✔️

[tamirms]

@2opremio @Shaptic do you still need this captiveCorePort field given that we have introduced captiveCoreHTTPPort? It seems like captiveCorePort and captiveCoreHTTPPort are both trying to configure the same port

[2opremio]

captiveCorePort is the peer port and not the http port. It should probably be tagged as such for clarity.