Serialize compact range options

[vweevers]

Closes #499.

The last commit (d54db39) (making start and end optional) started as an exercise, to see how the nullish/empty logic translates to compactRange. Answer: it's counterintuitive.

If, for symmetry with iterator range options, we cannot use a nullish start or end, then it only leaves '' as "not defined" signal. On the C++ LevelDB side, it is the other way around. We can do 5 things:

1. Nothing, because having to do compactRange('', 'z', cb) was already the case, though compactRange(null, 'z', cb) also worked (undocumented) and now it doesn't.
2. Revert d54db39, make it a problem for a later day
3. Forgo symmetry with iterator range options, so that e.g. compactRange(null, 'z', cb) compacts first key to 'z' but iterator({ gte: null, lte: 'z' }) targets 'null' to 'z'.
4. Have nullish mean "not defined" everywhere (Carefully consider behavior of nullish range options #515, comes with caveats), so that compactRange(null, 'z', cb) targets the same range as iterator({ gte: null, lte: 'z' }).
5. Introduce options object so that consumers don't need null, e.g. compactRange({ end: 'z' }, cb).

[ralphtheninja]

nice

[ralphtheninja]

Not sure what I prefer out of those options. I'm leaning towards 5.

[vweevers]

It's too bad that LevelDB doesn't support approximateSize of the full database, otherwise we could refactor that to take an options object too.

[vweevers]

Option 5 also makes it easier to introduce promise support in the future, i.e. making the callback optional. To do that while also making start and end optional would mean we'd have to detect the following call signatures:

compactRange(start, end, callback)
compactRange(start, callback)
compactRange(/* not-defined-signal */, end, callback)
compactRange(callback)
compactRange(start, end).then(..)
compactRange(start).then(..)
compactRange(/* not-defined-signal */, end).then(..)
compactRange().then(..)

Vs.

compactRange(options, callback)
compactRange(callback)
compactRange(options).then(..)
compactRange().then(..)

[vweevers]

I'd choose 5 if:

• approximateSize didn't exist or its arguments were optional in LevelDB
• We didn't already have many breaking changes (from abstract-leveldown)
• The C++ was cleaner. Because regardless of whether the public interface takes start and end arguments or an options argument, internally we'd need to default to '' and translate that to null on the C++ side. Using null on both sides would require more refactoring, to skip disposing slices. If anyone wants to take a stab at that though, go for it!

So at this time, I prefer option 2. That keeps the code simple (and easy to port to leveldown's friends):

leveldown/leveldown.js

Lines 78 to 83 in 0e3cda4

	LevelDOWN.prototype.compactRange = function (start, end, callback) {
	start = this._serializeKey(start)
	end = this._serializeKey(end)
	this.binding.compactRange(start, end, callback)
	}

PTAL

[vweevers]

Squash on merge.