clients/stellarcore: Add support for Core's new HTTP endpoints

[Shaptic]

Protocol 22/23: Core Endpoints

Epics: #5433, stellar/soroban-rpc#267

---

Stellar Core will have one new high-performance HTTP endpoints as part of their v22 in stellar/stellar-core#4350. It will have two more in v23. We need to support them. The endpoint schemas are defined in this document and are replicated here (please check the document to ensure the following schemas are not outdated).

Request format

Each endpoint needs to be implemented into the stellarcore client as its described here. The format for every endpoint is the same POST request:

ledgerSeq=N&key=base64&key=base64...

Here, ledgerSeq is an optional uint32 number and each key is a base64-encoded xdr.LedgerKey. If the ledgerSeq is not available on the given instance, a 404 will be returned.

Response formats

Protocol 22: /getledgerentry

JSON response (as a TypeScript interface):

interface Response {
  ledger: number; // uint32
  entries: {
    e: string; // base64-encoded xdr.LedgerEntry
    state: "live" | "new_entry_no_proof" | "new_entry_proof" | "archived_no_proof" | "archived_proof"
  }[]

Note that this is REPLACING the existing endpoint, meaning we need to ensure that all code paths that use the current variant of the endpoint are updated correctly. The best way to do this, in my opinion, is to remove the stellarcore.Client.GetLedgerEntry entirely and add support into a new GetLedgerEntries, so any code referencing the old method will break.

---

Protocol 23: /getinvocationproof

JSON response (as a TypeScript interface):

interface Response {
  ledger: number; // uint32
  proof?: string; // base64-encoded xdr.ArchivalProof
}

Note that if a proof is not required for any of the given entries, proof will be omitted.

Protocol 23: /getrestorationproof

JSON response (as a TypeScript interface):

interface Response {
  ledger: number; // uint32
  proof?: string; // base64-encoded xdr.ArchivalProof
}

Note that if a proof is not required for any of the given entries, proof will be omitted.

Notes

Core does not have a build ready with these endpoints so they cannot be tested end-to-end (hence the Blocked label). However, we can still implement the schemas in anticipation of these interfaces.