core/rawdb: separate raw database access to own package

[karalabe]

This PR is a cleanup effort for database accesses. There are various reasons why this refactor was done:

• The core package is becoming a monster. Everything and the kitchen sink is in there, and it's just too messy: we either create monster files (like the single database_utils.go previously) or have an unmanageable number of them in the same folder. By separating the raw database accessors out, we can have a nicely structured package with a single scope: directly read/write high level data structures from/to the database.
• Scoping wise, since everything was in core we created accessor methods that are useful only for us, but they are not usable by any community basing their work on top of go-ethereum. Anything we only needed in core was private, and anything needed outside was littering the namespace. By separating out these methods into rawdb, we ourselves are users of our own package, forcing us to create a decent for all our needed use cases, and thus raise the probability of it being generally useful.
• A lot of code we have (the light client is especially prone to this) does direct database accesses instead of using the caching mechanisms from inside the header/block chains. This results in suboptimal performance since we're doing disk reads all the time. These direct reads are very hard to catch/realize, because "it's just a method on core". By moving all these methods into rawdb, the caller should be painfully aware that they are doing direct database reads, not some fast operation.
• As we add more and more caches, we're starting to leak out database schema details into all our packages (e.g. trie is aware of the secure-trie preimage prefix used by the database to make some ops faster; bloombits is aware of index prefixes used by the database). By introducing a proper, clean package for raw database access, we can add all the metaoperations in there that other packages can use, thus cleaning up the implementation leak across our packages.

The PR also does a handful of code cleanups while at it:

• All GetXXX operations have been renamed ReadXXX. This is an API documentation aspect to help people better realize they are doing expensive operations, not some fast retrieval.
• All WriteXXX and DeleteXXX operations have been modified to not return an error on failure, rather flat out terminate internally. This is done because if a write fails, we're done, there's no way to recover from it. Currently all code doing direct database writes had if err := WriteXXX; err != nil { log.Crit } boilerplate code that just terminated geth. Some code even forgot to check the errors. By enforcing termination internally we avoid buggy and ugly code.
• Retrieving the number of a (header) hash now returns *uint64 instead of uint64. The old code returned 0xffffffffffffffff if a header was unknown, and then hoped calling code can make sense of this. This is very very brittle as any code using number comparison might blow up spectacularly due to a missing header.

Btw, the reason I need this change is because I've started working on an account cache/database layer on top of the raw db (similar to the trie write cache) and it's just too messy to keep adding stuff into core and/or to keep leaking stuff out into other packages.

[holiman]

LGTM at first read-through, will look over it again...

[holiman]

You are dereferencing rawdb.ReadHeaderNumber twice here. That method may return nil, which would crash here. Maybe some precondition higher up already guarantees that not to be the case, but if so it would be good if you make a comment about that.

[karalabe]

Yeah I saw it. But it's a test :D So crashing will result in a test failure.

[holiman]

LGTM (but I'd wait out the full-sync just in case)