Drop support of key types other than string and Buffer

[vweevers]

Background: #186.

Todo:

• Test against bytewise key-encoding on sub-level causes not found on other level  subleveldown#64 (cc @MeirionHughes)
• Test against Race condition level-ttl#68 (comment)
• Test against Add clear() abstract-leveldown#310

Should also remove the need for Level/codec#51.

[vweevers]

Does this warrant a prerelease? That hasn't proven itself useful in the past (on levelup, leveldown) mainly because there wasn't any feedback on prereleases.

[ralphtheninja]

Does this warrant a prerelease? That hasn't proven itself useful in the past (on levelup, leveldown) mainly because there wasn't any feedback on prereleases.

I think we can skip that, because no feedback and also yolo.

[MeirionHughes]

with "memdown": "git://github.com/Level/memdown.git#drop-custom-key-types", the failing test in https://github.com/Level/subleveldown/tree/tests/buffer-race-issue passes. I've hooked this up with my store db, switching from charewise to bytewise and its passing my unit tests.

[vweevers]

The race issues in level-ttl make it hard to tell if it is now compatible with memdown (less tests are failing, basically) so I also added a small test here, of mixed use of string and Buffer keys.

TLDR; everything looks good.

[vweevers]

One open question: this PR fixes keys, but similar issues exist on values. For example, assume we have a level-mem db with utf8 value encoding, then await db.put('key', Buffer.from('foo')); await db.get('key') yields a Buffer, but with leveldown we'd get a string.

Should we go all the way, and also drop custom value types?

[vweevers]

Should we go all the way, and also drop custom value types?

I say yes, because it's another incompatibility that isn't easy to solve otherwise. And it's common to swap keys and values (e.g. for indexing) so they should behave largely the same (I wish I realized this sooner).

Will open a second PR.