trie: add node type common package

[rjl493456442]

In trie/types package, a few node wrappers are defined, which will be used
in both trie package, trie/snap package, etc. Therefore, a standalone common
package is created to place these stuffs.

[karalabe]

Hmm, this seems a bit leaky to all of a sudden have trie depend on core/types. The core/types are very high level stuff vs the trie is a low level data structure. If you want to separate the nodes into their own package, perhaps have them in trie/types? Or can't trie/snap depend on trie?

[fjl]

The new package is not core/types, it's trie/types. The name isn't perfect though, types is too generic.
Depending on what else will be in this package, we could call it

• trie/trienode if only node types will be there
• trie/triedb if other database-related types will be added to this package later

[rjl493456442]

@karalabe Yes, I define stuffs in trie/types.

Or can't trie/snap depend on trie?

trie/snap will be imported by trie package, because trie.DatabaseWrapper is in trie package. And these types in trie/types will be used by trie(nodeset) and trie/snap. So we need another separate package.

@fjl I prefer trie/trienode. I expect this package will only be used to place some very common stuffs, like node wrapper. I think this name is more suitable.

[fjl]

Very nice! Let's go with trie/trienode then!

[rjl493456442]

What about trie/nodes then? Feel like trie/trienode is a bit too long. e.g. n *trienode.NodeWithPrev. But if you feel trie/nodes is also too general then I am fine with it.

[fjl]

When the package name is trienode, the type names can be shorter and do not need to contain Node.
So you can have a type name like *trienode.WithPrev.

[fjl]

Maybe trienode.Node is acceptable though?

If not, we can use trienode.Enc (encoded node) or trienode.Hashed (because it contains encoded + hash).

[rjl493456442]

Updated.

[karalabe]

SGTM