soroban-rpc: Add eta field for transactions for more efficient polling

[paulbellamy]

What problem does your feature solve?

When a user submits a txn, they have no idea when it will be included in a ledger, so the client has to poll frequently to check.

What would you like to see?

Add an eta field (as in stellar-deprecated/soroban-docs#289), to sendTransaction and getTransactionStatus, which is a timestamp of the earliest we would expect the transaction to be included in a ledger.

What alternatives are there?

• Don't do it
• Add websockets (or some other subscription/push notification system)

[tomerweller]

My vote is: "don't do it". ETA implies that soroban-rpc has an understanding of the state of core's transaction queue but core provides no such information

[leighmcculloch]

With the eta the longest a client will wait before polling is likely around 5 seconds.

If we assume that without an ETA the clients polls once every 0.5 seconds and the transaction is accepted in the next ledger, the presence of the ETA has the potential to save somewhere between 0 and 9 requests. Or 0 and 4 requests if the clients polls every 1 second.

Is that too many requests?

If the clients has to wait a while due to congestion it might add up.

How clever would we expect the eta to be? Would it be eta to next ledger only, or use other inputs like fees, and network load?

[tomerweller]

@leighmcculloch maybe instead of an ETA soroban-rpc can include a latest-ledger-ingested-timestamp (which is nice metadata to have for most endpoints) and then the client can determine an eta?

[tomerweller]

(when I originally read the description I thought that eta might try to take into account surge pricing, hence referencing the transaction queue)

[tamirms]

we added the last ledger close time to the response. from that an eta can be inferred (e.g. 5 seconds after the last ledger close time)