core/rawdb: implement resettable freezer

[rjl493456442]

This PR implements resettable freezer by adding a ResettableFreezer wrapper.

Freezer can truncate data from head or tail via truncation methods. Once items
are deleted from tail, a flag virtualTail will be updated in the corresponding
metadata file to indicate these items are not available anymore.

However, tail truncation is irreversible. In other words, these positions corresponding
to tail truncated can no longer store new data. The only way is to reset the entire
freezer.

In PBSS, freezer is used to restore trie history(reverse diff). These history items
will be truncated from tail. But it's possible that blockchain will be required to
rollback to genesis, which needs to reset the entire trie history(drop all of them).
So this function is needed in this case.

Implementation wise, it relies on the os.Rename and os.RemoveAll to atomically
delete the original freezer data and re-create a new one from scratch. The reason
is it's very hard to ensure the atomicity if we implement the reset in freezerTable level.

To be precise, a freezer will contain multiple tables inside. If a table is reset and
other are not(crash happens), then when the freezer is opened next time, all
tables will be trimmed to the same length, that is, the highest tail is selected as
the tail of the freezer, but it's impossible for the reset'd one.

[holiman]

LGTM, one nitpick

[holiman]

Couldn't things be simplified by having this look like :

Suggested change

	func NewResettableFreezer(datadir string, namespace string, readonly bool, maxTableSize uint32, tables map[string]bool) (*ResettableFreezer, error) {
	func NewResettableFreezer(f *Freezer) (*ResettableFreezer, error) {

It can pick out the datadir etc from f, no?

[rjl493456442]

I still need these parameters to re-create a new freezer instance once Reset happens.

[holiman]

But you can get them from the f, no?

[rjl493456442]

Theoretically yes, but in practice it's really inconvenient.
E.g. namespace is the prefix for metrics which is not stored in freezer
E.g. maxTableSize is passed to freezerTable which is also not stored in freezer

I would still prefer to keep all parameters passed in. I mean in implementation complexity wise.

[holiman]

👍

[zhiqiangxu]

@rjl493456442 where is this method called?

[rjl493456442]

It's used in my pbss code. Just open the PR for collecting some feedbacks.

[rjl493456442]

--- FAIL: TestResetFreezer (1.80s)
    testing.go:1097: TempDir RemoveAll cleanup: remove C:\Users\appveyor\AppData\Local\Temp\1\TestResetFreezer4134227925\001\FLOCK: The process cannot access the file because it is being used by another process.

Need fix

[holiman]

Triage discussion:

We need to ensure that the user-configurable datadir is not the folder which gets renamed during a reset. This is because it might be a mount, and when we rename it, it might become a local folder, causing a copy of hundreds of gigabyte.

As long as this is used for pbss, which already reside in a folder of the ancientdir, this is fine.

[karalabe]

I'd also like the constructor / data struct doc to contain some note of this limitation and that if we ever want to use it for ancients or configurable/mountable freezers, we need to swap from datadir atomic reset to some file based solution.