index sync creates data files for slice counts of (all?) databases

[travisturner]

Steps to recreate:

Against a completely empty Pilosa instance, run the following:

curl -X POST "http://127.0.0.1:15000/query?db=wideDB" -d 'SetBit(id=10, frame="foo", profileID=1)'
curl -X POST "http://127.0.0.1:15000/query?db=wideDB" -d 'SetBit(id=10, frame="foo", profileID=10000000)'
curl -X POST "http://127.0.0.1:15000/query?db=narrowDB" -d 'SetBit(id=20, frame="foo", profileID=1)'
curl -X POST "http://127.0.0.1:15000/query?db=narrowDB" -d 'SetBit(id=20, frame="foo", profileID=1300000)'

This creates two databases.
wideDB contains data in slices 0 and 9
narrowDB contains data in slices 0 and 1

The data file tree looks like this:

├── narrowDB
│   ├── data
│   └── foo
│       ├── 0
│       ├── 0.cache
│       ├── 1
│       ├── 1.cache
│       └── data
└── wideDB
    ├── data
    └── foo
        ├── 0
        ├── 0.cache
        ├── 9
        ├── 9.cache
        └── data

After index sync runs, the data file tree looks like this:

├── narrowDB
│   ├── data
│   └── foo
│       ├── 0
│       ├── 0.cache
│       ├── 1
│       ├── 1.cache
│       ├── 2
│       ├── 3
│       ├── 4
│       ├── 5
│       ├── 6
│       ├── 7
│       ├── 8
│       ├── 9
│       └── data
└── wideDB
    ├── data
    └── foo
        ├── 0
        ├── 0.cache
        ├── 1
        ├── 2
        ├── 3
        ├── 4
        ├── 5
        ├── 6
        ├── 7
        ├── 8
        ├── 9
        ├── 9.cache
        └── data

Notice that narrowDB now contains 10 slices, even though only wideDB should contain 10 slices.

[travisturner]

This will get resolved with the db-specific MaxSlice code that I'm working on.

[travisturner]

This is addressed by #152