exp/services/captivecore/internal: Add HTTP server for managing a remote captive core instance

[tamirms]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

Add HTTP server for managing a remote captive core instance.

Why

From #2841 :

The current implementation of Captive Stellar-Core streams meta stream using a filesystem pipe. This implies that both Horizon and Stellar-Core have to be deployed to the same server. One of the disadvantages of such requirement is a need for detailed per-process monitoring to be able to connect potential issues (like memory leaks) to the specific service.

To solve this we can build a thin wrapper around CaptiveStellarCore backend that exposes a simple RPC/HTTP API similar to LedgerBackend interface:

 // LedgerBackend represents the interface to a ledger data store. 
 type LedgerBackend interface { 
 	// GetLatestLedgerSequence returns the sequence of the latest ledger available 
 	// in the backend. 
 	GetLatestLedgerSequence() (sequence uint32, err error) 
 	// The first returned value is false when the ledger does not exist in a backend. 
 	GetLedger(sequence uint32) (bool, xdr.LedgerCloseMeta, error) 
 	// PrepareRange prepares the given range (including from and to) to be loaded. 
 	// Some backends (like captive stellar-core) need to initalize data to be 
 	// able to stream ledgers. 
 	PrepareRange(ledgerRange Range) error 
 	// IsPrepared returns true if a given ledgerRange is prepared. 
 	IsPrepared(ledgerRange Range) bool 
 	Close() error 
 } 

The full solution requires a server and a client that can consume the API.

A server can be a subcommand on horizon that exposes the CaptiveStellarCore object API using either the net/rpc package or HTTP. It has the same require params as CaptiveStellarCore. A server is a singleton, meaning it can start a single stellar-core process, thus should be used by a single Horizon instance.

A client, RemoteCaptiveStellarCore implementation of LedgerBackend interface is part of exp/ingest/ledgerbackend and accepts a connection params to a server.

Known limitations

I will add tests in a subsequent commit. Right now I'm looking for a preliminary review

[bartekn]

Nit: I think form urlencoded would be much simpler here. JSON is fine but we don't really need it here.

[tamirms]

I think it's slightly easier for the client code to use JSON because serializing to JSON would require less code than constructing an HTTP form. Also, it is nice to make the content type consistent between the request and response bodies.

[bartekn]

Does it render as base64? If not the value will be really hard to parse.

[tamirms]

@bartekn can you take another look? I've added tests now