Add transaction for the operation of insert #6244

[pengxiangyu]

Proposed changes

Add transaction for the operation of insert. It will cost less time than non-transaction(it will cost 1/1000 time) when you want to insert a amount of rows.

Syntax

BEGIN [ WITH LABEL label];
INSERT INTO table_name ...
[COMMIT | ROLLBACK];

Example

commit a transaction:

begin;
insert into Tbl values(11, 22, 33);
commit;

rollback a transaction:

begin;
insert into Tbl values(11, 22, 33);
rollback;

commit a transaction with label:

begin with label test_label;
insert into Tbl values(11, 22, 33);
commit;

Description

begin:  begin a transaction, the next insert will execute in the transaction until commt/rollback;
commit:  commit the transaction, the data in the transaction will be inserted into the table;
rollback:  abort the transaction, nothing will be inserted into the table;

The main realization principle:

1. begin a transaction in the session. next sql is executed in the transaction;
2. insert sql will be parser and get the database name and table name, they will be used to select a be and create a pipe to accept data;
3. all inserted values will be sent to the be and write into the pipe;
4. a thread will get the data from the pipe, then write them to disk;
5. commit will complete this transaction and make these data visable;
6. rollback will abort this transaction

Some restrictions on the use of update syntax.

1. Only insert can be called in a transaction.
2. If something error happened, commit will not succeed, it will rollback directly;
3. By default, if part of insert in the transaction is invalid, commit will only insert the other correct data into the table.
4. If you need commit return failed when any insert in the transaction is invalid, you need execute set enable_insert_strict = true before begin.

Types of changes

What types of changes does your code introduce to Doris?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)
• Code refactor (Modify the code structure, format the code, etc...)
• Optimization. Including functional usability improvements and performance improvements.
• Dependency. Such as changes related to third-party components.
• Other.

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have created an issue on (Fix Add transaction for the operation of insert #6244) and described the bug/feature there in detail
• Compiling and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• If these changes need document changes, I have updated the document
• Any dependent changes have been merged

Further comments

[morningman]

Please add the motivation and benefits of this feature in your issue.

[morningman]

Please also add document for this feature, for both syntax doc and usage doc.
You can refer to #6230

[morningman]

LGTM