feat: refactor manifest to get snapshot in memory

[Rachelint]

Which issue does this PR close?

Closes #
Part of #799

Rationale for this change

Make snapshot able to get snapshot from table data.

What changes are included in this PR?

Make snapshot able to get snapshot from table data.

Are there any user-facing changes?

None.

How does this change test

Test by ut.

[ShiKaiWi]

This solution sounds good. However, there may be one potential problem in it. Here is an example for it:

1. The manifest wal is updated;
2. Snapshot is triggered;
3. Table metadata in the memory is used to form the latest snapshot;

In the step 3, the table metadata (snapshot) may be different from the logs from manifest wal.

[Rachelint]

This solution sounds good. However, there may be one potential problem in it. Here is an example for it:

1. The manifest wal is updated;

2. Snapshot is triggered;

3. Table metadata in the memory is used to form the latest snapshot;

In the step 3, the table metadata (snapshot) may be different from the logs from manifest wal.

In fact, this situation will not be occurred.
Snapshot works always done before writing the new comming logs to log store.

[ShiKaiWi]

This solution sounds good. However, there may be one potential problem in it. Here is an example for it:

1. The manifest wal is updated;

2. Snapshot is triggered;

3. Table metadata in the memory is used to form the latest snapshot;

In the step 3, the table metadata (snapshot) may be different from the logs from manifest wal.

In fact, this situation will not be occurred. Snapshot works always done before writing the new comming logs to log store.

After some thoughts, I'm still worried about that the table metadata in the memory is not controlled by the manifest, that is to say, the order of updating manifest before the table metadata in memory is implicit. Maybe we can extend the TableSnapshotProvider to TabeSnapshotManager which is not only able to provide the latest snapshot but also receive metadata updates.

[Rachelint]

This solution sounds good. However, there may be one potential problem in it. Here is an example for it:

1. The manifest wal is updated;

2. Snapshot is triggered;

3. Table metadata in the memory is used to form the latest snapshot;

In the step 3, the table metadata (snapshot) may be different from the logs from manifest wal.

In fact, this situation will not be occurred. Snapshot works always done before writing the new comming logs to log store.

After some thoughts, I'm still worried about that the table metadata in the memory is not controlled by the manifest, that is to say, the order of updating manifest before the table metadata in memory is implicit. Maybe we can extend the TableSnapshotProvider to TabeSnapshotManager which is not only able to provide the latest snapshot but also receive metadata updates.

I will sovle it in next pr.

[ShiKaiWi]

LGTM