[Tracking] Refactor UpdateTransaction

Currently UpdateTransaction holds a global lock and blocks any other insertion/read since the UpdateTransaction starts.
However, it is possible to split UpdateTransaction into two stages.
First stage, UpdateTransaction maintains all changes copy on write, which will not effect the view for snapshots before this timestamp. So both insert transaction and read transaction could be parallelized with UpdateTransaction.
Second stage, UpdateTransaction begins to commit. At this time, a global lock is acquired, and no other transactions are allowed.

In addition, the transaction system currently lacks rollback capability when errors occur during the commit phase. This leads to partial commits that violate transaction atomicity.

Two specific scenarios are affected:

Insert transaction: Partial vertex insertions cannot be rolled back when a subsequent insert fails.
Update transaction: Schema drop operations cannot be undone once data is deleted, because bulk operations (drop/copy) lack WAL support.
See sub-issues #315 and #316 for detailed descriptions of each problem.