trie: fix bloom crash on fast sync restart

[karalabe]

This PR fixes

panic: runtime error: invalid memory address or nil pointer dereference
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x7ed606]

goroutine 2907 [running]:
github.com/ethereum/go-ethereum/trie.(*SyncBloom).Add(0x0, 0xc023631818, 0x20, 0x20)
	/work/src/github.com/ethereum/go-ethereum/trie/sync_bloom.go:161 +0x26
github.com/ethereum/go-ethereum/trie.(*Sync).Commit(0xc01b891e00, 0x159fb40, 0xc007dd3180, 0x40, 0xc0236319f8)
	/work/src/github.com/ethereum/go-ethereum/trie/sync.go:316 +0x18c
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).commit(0xc035672a00, 0x1, 0xc00032bc00, 0x0)
	/work/src/github.com/ethereum/go-ethereum/eth/downloader/statesync.go:417 +0x99
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).loop.func1(0xc035672a00, 0xc023631f70)
	/work/src/github.com/ethereum/go-ethereum/eth/downloader/statesync.go:351 +0x30
panic(0x11e1aa0, 0x1c5e540)
	/opt/google/go/src/runtime/panic.go:969 +0x1b9
github.com/ethereum/go-ethereum/trie.(*SyncBloom).Add(0x0, 0xc023631c08, 0x20, 0x20)
	/work/src/github.com/ethereum/go-ethereum/trie/sync_bloom.go:161 +0x26
github.com/ethereum/go-ethereum/trie.(*Sync).Commit(0xc01b891e00, 0x159fb40, 0xc007dd3160, 0xc0338a978c, 0x1448138)
	/work/src/github.com/ethereum/go-ethereum/trie/sync.go:316 +0x18c
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).commit(0xc035672a00, 0x100, 0xc002fe6881fadee8, 0x1b08579001)
	/work/src/github.com/ethereum/go-ethereum/eth/downloader/statesync.go:417 +0x99
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).loop(0xc035672a00, 0x0, 0x0)
	/work/src/github.com/ethereum/go-ethereum/eth/downloader/statesync.go:359 +0x157
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).run(0xc035672a00)
	/work/src/github.com/ethereum/go-ethereum/eth/downloader/statesync.go:320 +0xde
created by github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).runStateSync
	/work/src/github.com/ethereum/go-ethereum/eth/downloader/statesync.go:114 +0x1ef

If we roll back the chain to before the pivot block, that will reenable fast sync. However, the sync bloom filter is only allocated on startup. If we've just done an initial sync, and did setHead, it still works because the bloom is not nil, just closed. However if we've already synced and started the node with an existing chain, the bloom will be nil. Reenabling fast sync at that point crashes.

This PR fixes it by having trie.Sync gracefully handle a nil bloom too, not just a closed bloom. It's fine not to rebuild the bloom in this case because we're probably only missing a few hundred trie nodes and it's not worth reading through the entire database and allocating gigabytes just to dedup a few hundred potential database reads.

[holiman]

LGTM