WIP: Improve db interface

add metalinter to CI and address some lint warnings

Develop

db: fix MemDB.Close

This is needed because leveldb reuses the keys on each iteration.
In our wrapper, we copy the key/value so that it is safe to store.

We need this to properly support LevelDB backend, which needs
to be released if we don't want to leak memory.

Fixes https://github.com/tendermint/tmlibs/issues/55

MemDB previously mistakenly set the actual DB pointer to nil
although that side effect is not visible to the outside world
since p is an identifier within the scope of just that function
call. However, @melekes and I had a discussion in which we
came to the conclusion that Close for an in-memory DB should
instead be a noop and not cause any data loss. See the
discussion on https://github.com/tendermint/tmlibs/pull/56.

common: WriteFileAtomic use tempfile in current dir

v0.3.0

call fsync after flush

short: flushing the bufio buffer is not enough to ensure data
consistency.

long:
Saving an entry to the WAL calls writeLine to append data to the
autofile group backing the WAL, then calls group.Flush() to flush that
data to persistent storage. group.Flush() in turn proxies to
headBuf.flush(), flushing the active bufio.BufferedWriter. However,
BufferedWriter wraps a Writer, not another BufferedWriter, and the way
it flushes is by calling io.Writer.Write() to clear the BufferedWriter's
buffer. The io.Writer we're wrapping here is AutoFile, whose Write
method calls os.File.Write(), performing an unbuffered write to the
operating system, where, I assume, it sits in the OS buffers awaiting
sync. This means that Wal.Save does not, in fact, ensure the saved
operation is synced to disk before returning.

See https://github.com/go-kit/kit/issues/164 for discussion of why
kitlog returns an error.

```
Package log is designed to be used for more than simple application info/warning/error logging; it's suitable for log-structured data in an e.g. Lambda architecture, where each invocation is important. I agree with you that if we were doing only application logging the error would be more noise than signal. But the scope of the package is larger than that.
```

Since we are doing only application logging and we're not checking
errors, it is safe to get rid them.

Log tweak

common/IsDirEmpty: do not mask non-existance errors

Fix rename /root/.tendermint_test/consensus_replay_test/priv_validator.json.new /root/.tendermint_test/consensus_replay_test/priv_validator.json: no such file or directory

[pubsub/query] quote values using single quotes

Currently IsDirEmpty returns true, err if it encounters
any error after trying to os.Open the directory.
I noticed this while studying the code and recalled a bug
from an earlier project in which doing the exact same thing
on code without permissions would trip out and falsely report
that the directory was empty.
Given demo.go in https://play.golang.org/p/vhTPU2RiCJ

* Demo:
```shell
$ mkdir -p sample-demo/1 && touch sample-demo/2
$ echo "1st round" && go run demo.go sample-demo
$ sudo chown root sample-demo && sudo chmod 0700 sample-demo
$ echo "2nd round" && go run demo.go sample-demo
```

That then prints out
```shell
1st round
original:: empty: false err: <nil>
updated::  empty: false err: <nil>
2nd round
original:: empty: true err: open data/: permission denied
updated::  empty: false err: open data/: permission denied
```

where in "2nd round", the original code falsely reports that
the directory is empty but that's a permission error.

I could write a code test for it, but that test requires me to change
users and switch to root as a Go user so no point in complicating our
tests, but otherwise it is a 1-to-1 translation between shell and Go.

http: http-utils added after extraction

Found common http utils that were being multiply duplicated across
many libraries and since am moving things in basecoin/unstable to
add for more functionality, it's better to put them in one
place.

Utilities and tests added:
- [X] FparseJSON
- [X] FparseAndValidateJSON
- [X] ParseRequestJSON
- [X] ParseAndValidateRequestJSON
- [X] WriteCode
- [X] WriteError
- [X] WriteSuccess
- [X] ErrorResponse

During review from @ethanfrey, made updates:
* Removed tt.want since it was a distraction/artifact that made
the reviewer think the tests weren't testing for both failed
and passed results.
* Added ErrorWithCode as WithCode is a common options pattern
in Go that could cause confusion:
  ErrorWithCode(error, int) ErrorResponse
* Using json.NewDecoder(io.Reader) error instead of
ioutil.ReadAll(io.Reader) to slurp all the bytes.
* Added more test scenarios to achieve 100% coverage of http.go

We use WriteFileAtomic in two places:

```
p2p/addrbook.go
338:    err = cmn.WriteFileAtomic(filePath, jsonBytes, 0644)

types/priv_validator.go
162:    err = WriteFileAtomic(privVal.filePath, jsonBytes, 0600)
```

and we don't need .bak in any of the above. We save priv_validator every
10ms and addrbook every 2 min.

The problem with {filePath}.new is that it is not safe for concurrent
use! Calling this function with the same params results in the following
error:

```
panic: Panicked on a Crisis: rename /root/.tendermint_test/consensus_replay_test/priv_validator.json.new /root/.tendermint_test/consensus_replay_test/priv_validator.json: no such file or directory

goroutine 47860 [running]:
github.com/tendermint/tendermint/vendor/github.com/tendermint/tmlibs/common.PanicCrisis(0xcba800, 0xc42152d640)
	/go/src/github.com/tendermint/tendermint/vendor/github.com/tendermint/tmlibs/common/errors.go:33 +0x10f
github.com/tendermint/tendermint/types.(*PrivValidator).save(0xc42235f2c0)
	/go/src/github.com/tendermint/tendermint/types/priv_validator.go:165 +0x159
github.com/tendermint/tendermint/types.(*PrivValidator).signBytesHRS(0xc42235f2c0, 0x6, 0x0, 0xc424e88f03, 0xc429908580, 0xca, 0x155, 0x80, 0xc424e88f00, 0x7f4ecafc88d0, ...)
	/go/src/github.com/tendermint/tendermint/types/priv_validator.go:249 +0x2bb
github.com/tendermint/tendermint/types.(*PrivValidator).SignVote(0xc42235f2c0, 0xc4228c7460, 0xf, 0xc424e88f00, 0x0, 0x0)
	/go/src/github.com/tendermint/tendermint/types/priv_validator.go:186 +0x1a2
github.com/tendermint/tendermint/consensus.(*ConsensusState).signVote(0xc424efd520, 0xc400000002, 0xc422d5e3c0, 0x14, 0x20, 0x1, 0xc4247b6560, 0x14, 0x20, 0x0, ...)
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:1556 +0x35e
github.com/tendermint/tendermint/consensus.(*ConsensusState).signAddVote(0xc424efd520, 0x2, 0xc422d5e3c0, 0x14, 0x20, 0x1, 0xc4247b6560, 0x14, 0x20, 0xc42001b300)
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:1568 +0x200
github.com/tendermint/tendermint/consensus.(*ConsensusState).enterPrecommit(0xc424efd520, 0x6, 0x0)
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:1082 +0x13a4
github.com/tendermint/tendermint/consensus.(*ConsensusState).addVote(0xc424efd520, 0xc424e88780, 0x0, 0x0, 0x39, 0x1dc, 0x28c)
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:1477 +0x1be5
github.com/tendermint/tendermint/consensus.(*ConsensusState).tryAddVote(0xc424efd520, 0xc424e88780, 0x0, 0x0, 0xd7fb00, 0xc42152ce00)
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:1382 +0x93
github.com/tendermint/tendermint/consensus.(*ConsensusState).handleMsg(0xc424efd520, 0xcb58e0, 0xc42547feb8, 0x0, 0x0, 0x6, 0x0, 0x4, 0xed10ca07e, 0x3077bfea, ...)
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:660 +0x9fc
github.com/tendermint/tendermint/consensus.(*ConsensusState).receiveRoutine(0xc424efd520, 0x0)
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:615 +0x5f5
created by github.com/tendermint/tendermint/consensus.(*ConsensusState).OnStart
	github.com/tendermint/tendermint/consensus/_test/_obj_test/state.go:332 +0x4a7
exit status 2
FAIL	github.com/tendermint/tendermint/consensus	76.644s
make: *** [test_integrations] Error 1
```

See https://github.com/tendermint/tendermint/pull/568

This fixes the problem with base-16 encoded values which may start with
digits: 015AB.... In such cases, the parser recognizes them as numbers
but fails to parse because of the follow-up characters (AB).

```
failed to parse tm.events.type=Tx AND hash=136E18F7E4C348B780CF873A0BF43922E5BAFA63:
parse error near digit (line 1 symbol 31 - line 1 symbol 32):
  "6"
```

So, from now on we should quote any values. This seems to be the way
Postgresql has chosen.

New pubsub package plus the query subpackage

test UnsubscribeAll properly
test BufferCapacity getter