Use dump endpoint for turso db shell $DB .dump

[athoscouto]

This is a quick fix to enable folks to get dumps of arbitrary size.
We should patch the libsql-shell-go to use the endpoint instead of its own implementation.

---

Tested with:

> turso db shell flying-circuit      
Connected to flying-circuit at https://flying-circuit-athoscouto.turso.io

Welcome to Turso SQL shell!

Type ".quit" to exit the shell and ".help" to list all available commands.

→  select count(*) from fly;
COUNT (*) 
33554432      
→  .quit
> turso db shell flying-circuit .dump > fly.dump
> wc -l fly.dump 
 33554437 fly.dump
> head fly.dump 
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE IF NOT EXISTS libsql_wasm_func_table (name text PRIMARY KEY, body text) WITHOUT ROWID;
CREATE TABLE IF NOT EXISTS fly(a);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
> tail fly.dump 
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
INSERT INTO fly VALUES(1);
COMMIT;

[haaawk]

I'm not sure whether this works correct.

╰──> turso db shell dumptest ".dump"
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE IF NOT EXISTS libsql_wasm_func_table (name text PRIMARY KEY, body text) WITHOUT ROWID;
COMMIT;

We probably don't want the dump of libsql_wasm_func_table, do we?

[athoscouto]

@haaawk I don't know. Can users register functions? If so it makes sense to have it on the dump. It may be work to create a issue ok sqld repo about it.

[haaawk]

I think it's fine the way it is for now.