soroban-rpc: Enforce atomicity within jsonrpc request batches

[paulbellamy]

What problem does your feature solve?

See discussion in #48

Currently the jsonrpc server provides support for request batching automatically. But, those requests are all processed in parallel with no atomicity guarantees between them. So, one response might be as of ledger x, and another could be as of ledger x+1.

What would you like to see?

We should use a single database transaction for a batch.

This means we need to:

• Change the jsonrpc server to so that we can detect batches instead of having them handled automatically (I assume, check the docs).
  • This will mean some spelunking through the jrpc library and docs https://pkg.go.dev/github.com/creachadair/jrpc2?utm_source=godoc
• Refactor the database transaction system so we can use a transaction for a whole batch. In the past I've done this with something roughly like:

type DB interface {
  // Standard db methods and stuff
  Exec(ctx context.Context, query string, ...args interface{}) error    
  io.Closer
  // etc

  // Execute some code in a transaction
  Transaction(fn func(db DB) error) error
}

func (d *sqliteDB) Transaction(fn func(db DB) error) error {
  tx := txWrapper{d.BeginTx()}
  err := fn(tx)
  if err == nil {
    tx.Commit()
  } else {
    tx.Rollback()
  }
  return err
}

// txWrapper implements the DB interface
type txWrapper struct {
  *Transaction
}

// Standard db methods implemented on txWrapper
// func (tx *txWrapper) Exec(ctx context.Context, query string, ...args interface{}) error    
// etc

func (tx *txWrapper) Transaction(fn (d DB) error) error {
  // We are already in a transaction, no-op.
  return fn(tx)
}

func main() {
  conn := sqlite.Open(...)
  conn.Transaction(func(db DB) error {
    // This code now is in a transaction, but it doesn't know that.
    return db.Transaction(func(db DB) error {
      // It can nest transactions, but this will still only open a single transaction with the database.
    })
  })
}

What alternatives are there?

Don't do it, and tell users there is not atomicity within batches.