soroban-rpc: Better state expiration support for `getLedgerEntry`

[dmkozh]

Currently getLedgerEntry endpoint just returns the LE XDR, which now doesn't have the expiration-related info.

Instead it probably should:

• Return the entry expiration ledger (fetched from the respective EXPIRATION entry), when applicable
• Return a flag denoting whether entry has expired, when applicable

This would make the behavior consistent with simulation, where we already do fetch and mark the restored entries (when available).

[Shaptic]

Related, as a more-immediate workaround: stellar/js-soroban-client#153

[tsachiherman]

I don't believe that Return a flag denoting whether entry has expired, when applicable is really needed :
The response include the LatestLedger as well as ExpirationLedger per ledger key.
The client can compare to see if ExpirationLedger < LatestLedger and deduce that the entry have expired.

In the future, when the RPC would want to provide the "information" that the entry has expired, but wouldn't know when, it could return ExpirationLedger == 0, which would align with the existing logic.

[tsachiherman]

@Shaptic @sreuland @dmkozh ☝️

[sreuland]

I don't believe that Return a flag denoting whether entry has expired, when applicable is really needed

sounds good, so, the net change would reduce to just new 👍

type LedgerEntryResult struct {
	...
        ExpirationLedger int64 `json:"expirationLedgerSeq,string,omitempty"`
}

with additional behavior of:

1. it's optional, will be absent if not applicable for LE?
2. if present it could be 0 meaning the LE has no expiration, or non-zero indicates a real ledger number that LE will expire upon.

[tsachiherman]

If it returns, the LE definitely has an expiration. The only question is whether a value of 0 is the right way to say "I don't know which ledger sequence it was expired upon" or whether we should find another way to achieve that.
I think that it's not a decision we have to make right now.

[sreuland]

If it returns, the LE definitely has an expiration. The only question is whether a value of 0 is the right way to say "I don't know which ledger sequence it was expired upon" or whether we should find another way to achieve that. I think that it's not a decision we have to make right now.

ok, is there a provision in spec for any type of LE's to not expire, and therefore have no expiration ledger, where 0 could denote that?

[tsachiherman]

of course. only contract_data and contract_code would expire.. all the rest of the entries have no expiration associated with them ( at least for now ).