Add SQLite Persistence tests

[arzonus]

What changed?

• sqlite.DB supports its custom errors
• Some queries from MySQL are migrated to SQLite:
  • DELETE ... ORDER BY ... LIMIT query syntax is not supported and is replaced by WITH-clause.
  • FOR UPDATE and LOCK IN SHARE MODE settings are not supported, however, the transaction level in SQLIte is serializable.
  • INSERT IGNORE INTO query syntax is not supported and replaced by INSERT OR IGNORE INTO
• Persistence tests are added for sqlite package
• buffered_events.id type has been changed from BIGINT to INT due AUTOINCREMENT is not supported for PRIMARY KEY BIGINT type.

Why?
SQLite storage will be used in the future as an in-memory replacement for persistence storage. The diff is a part of the project In-Memory Storage.

Previous PRs:

• Add SQLite plugin #6689
• Add SQLite plugin #6643
• Add SQLite package #6637

How did you test it?

• Unit tests

Potential risks
New changes in MySQL persistence layer may require some changes for SQLIte version if they're not compatible with SQLIte version.

Release notes

Documentation Changes

Detailed Description
[In-depth description of the changes made to the schema or interfaces, specifying new fields, removed fields, or modified data structures]

Impact Analysis

• Backward Compatibility: [Analysis of backward compatibility]
• Forward Compatibility: [Analysis of forward compatibility]

Testing Plan

• Unit Tests: [Do we have unit test covering the change?]
• Persistence Tests: [If the change is related to a data type which is persisted, do we have persistence tests covering the change?]
• Integration Tests: [Do we have integration test covering the change?]
• Compatibility Tests: [Have we done tests to test the backward and forward compatibility?]

Rollout Plan

• What is the rollout plan?
• Does the order of deployment matter?
• Is it safe to rollback? Does the order of rollback matter?
• Is there a kill switch to mitigate the impact immediately?

[Shaddoll]

As a part of history queue revamping, we're planning to introduce new tables in SQL implementations and store transfer tasks, replication tasks and timer tasks in them so that we can easily introduce new categories of history tasks in the future.

The schema change is not done for mysql and postgres sql because it's not prioritized. But it would be nice if we can implement the change for SQLLite.

CREATE TABLE history_immediate_tasks(
  shard_id INT NOT NULL,
  category_id INT NOT NULL,
  task_id BIGINT NOT NULL,
  --
  data MEDIUMBLOB NOT NULL,
  data_encoding VARCHAR(16) NOT NULL,
  PRIMARY KEY (shard_id, category_id, task_id)
);

CREATE TABLE history_scheduled_tasks (
  shard_id INT NOT NULL,
  category_id INT NOT NULL,
  visibility_timestamp DATETIME(6) NOT NULL,
  task_id BIGINT NOT NULL,
  --
  data MEDIUMBLOB NOT NULL,
  data_encoding VARCHAR(16) NOT NULL,
  PRIMARY KEY (shard_id, category_id, visibility_timestamp, task_id)
);

Do you mind making this change in your PR and update the SQL queries for transfer task, replication tasks and timer tasks?
(The interface of SQL plugin doesn't need to be changed because MySQL, PostgresSQL and Docstore will still use transfer_tasks, replication_tasks, timer_tasks table. Only change the SQL queries of SQLLite is fine.)

[3vilhamster]

Looks good. Looking forward to starting using this for minimal setup instead of Cassandra

[arzonus]

As a part of history queue revamping, we're planning to introduce new tables in SQL implementations and store transfer tasks, replication tasks and timer tasks in them so that we can easily introduce new categories of history tasks in the future.

The schema change is not done for mysql and postgres sql because it's not prioritized. But it would be nice if we can implement the change for SQLLite.

CREATE TABLE history_immediate_tasks(
  shard_id INT NOT NULL,
  category_id INT NOT NULL,
  task_id BIGINT NOT NULL,
  --
  data MEDIUMBLOB NOT NULL,
  data_encoding VARCHAR(16) NOT NULL,
  PRIMARY KEY (shard_id, category_id, task_id)
);

CREATE TABLE history_scheduled_tasks (
  shard_id INT NOT NULL,
  category_id INT NOT NULL,
  visibility_timestamp DATETIME(6) NOT NULL,
  task_id BIGINT NOT NULL,
  --
  data MEDIUMBLOB NOT NULL,
  data_encoding VARCHAR(16) NOT NULL,
  PRIMARY KEY (shard_id, category_id, visibility_timestamp, task_id)
);

Do you mind making this change in your PR and update the SQL queries for transfer task, replication tasks and timer tasks? (The interface of SQL plugin doesn't need to be changed because MySQL, PostgresSQL and Docstore will still use transfer_tasks, replication_tasks, timer_tasks table. Only change the SQL queries of SQLLite is fine.)

I have a feeling that it will require me to adapt all other queries that I am not aware of. Would it be possible to have these changes later in another PR? SQLite is fully based on MySQL, and I wouldn't like the merge logic here and have the PR focusing only on existing queries.