Graphql-engine: add a configurable statement_timeout on console raw sql page

[rikinsk]

To avoid accidently running a very heavy query on the database, the console can set a configurable transaction level statement_timout of 10 seconds.

If a user updates this value, the changed value should be persisted in local storage and used when the raw sql page is accessed subsequently.

The tooltip for the statement timeout input should be: Abort queries that take longer than the specified time

A statement_timout for a transaction can be set by adding the following SQL statement before the actual query (the server runs each query in a transaction so nothing needs to be done for that)

SET LOCAL statement_timeout = 10000;   # note that statement_timout expects input in milliseconds

[gokulchandra]

@rikinsk I can work on this..

[rikinsk]

@gokulchandra Please go for it! cc: @beerose.

[gokulchandra]

re: #5045

@rikinsk I was wondering if you could clarify this statement:

A statement_timout for a transaction can be set by adding the following SQL statement before the actual query (the server runs each query in a transaction so nothing needs to be done for that)

Does this mean that each arg within a bulk type is run in an individual transaction? Or all args are run in the same transaction?

Reason I ask is because based on how the queries are executed we could either prepend the statement_timeout query. eg:

{
    "type": "bulk",
    "args": [{
        "type": "run_sql",
        "args": {
            "sql": "SET LOCAL statement_timeout = 100000;",
            "cascade": false,
            "read_only": false
        }
    }, {
        "type": "run_sql",
        "args": {
            "sql": "select * from sample;",
            "cascade": false,
            "read_only": false
        }
    }]
}

Or just update the run_sql query string to have the statement_timeout SQL.

{
    "type": "bulk",
    "args": [{
        "type": "run_sql",
        "args": {
            "sql": "SET LOCAL statement_timeout = 100000; select * from sample;",
            "cascade": false,
            "read_only": false
        }
    }]
}

[rikinsk]

I would suggest to use the latter approach as it keeps the scope as close to the statement being executed without having to worry about the semantics of bulk

[gokulchandra]

Fair enough. Will update the PR accordingly