Change in manual compaction behavior with dynamic_level_bytes

We noticed a change in behavior with manual compaction when dynamic_level_bytes is being used, while we were upgrading from rocksdb v5.10 to v6.4.

The use case
Migrate a column family from one db to another (cross node data migration).
Methodology
1) Scan the keys on sender side and send to receiver (data spit into chunks during transfer)
2) Receiver creates a new column family with auto compaction disabled
3) Writes the data chunk at a time (no overlaps)
4) Triggers a manual compaction once all the data is transferred and then enables auto compaction

Expected behavior (as was in 5.10)
After step 4 above appropriate number of sst files on last level as per the target_file size for the given amount of data in the column family

Actual behavior (as in 6.4)
After step 4 above large number of set file with target file size corresponding to L1 level, as they are seemingly getting moved from L1 without compaction.

With a unit test, we were able to narrow down this to the change here
https://github.com/facebook/rocksdb/issues/3229

Steps to reproduce:
- Create a db with options
options.level_compaction_dynamic_level_bytes = true;
options.target_file_size_base = 20960;
options.target_file_size_multiplier = 4;
options.max_bytes_for_level_base = 40960;
options.max_bytes_for_level_multiplier = 4;
options.max_background_compactions = 2;
options.num_levels = 5;

- Disable auto compaction
- Write ~2800K of data
- Flush and Compact

Good case we see
Name default, File count 6
Level 0, File Count 0
Level 1, File Count 0
Level 2, File Count 0
Level 3, File Count 0
Level 4, File Count 6
FileName /000103.sst, size 537968
FileName /000104.sst, size 537978
FileName /000105.sst, size 537957
FileName /000106.sst, size 537975
FileName /000107.sst, size 538005
FileName /000108.sst, size 176920

Bad case we see
Name default, File count 127
Level 0, File Count 0
Level 1, File Count 0
Level 2, File Count 0
Level 3, File Count 0
Level 4, File Count 127
FileName /000104.sst, size 23486
FileName /000105.sst, size 23497
FileName /000107.sst, size 23497
FileName /000108.sst, size 23493
FileName /000109.sst, size 23493
FileName /000110.sst, size 23497
FileName /000111.sst, size 23496
FileName /000112.sst, size 23489
FileName /000113.sst, size 23493
FileName /000114.sst, size 23497
FileName /000115.sst, size 23496
FileName /000116.sst, size 23500
FileName /000117.sst, size 23495
FileName /000118.sst, size 23496
FileName /000119.sst, size 23492
FileName /000120.sst, size 23499
FileName /000121.sst, size 23504
FileName /000122.sst, size 23492
FileName /000123.sst, size 23500
FileName /000124.sst, size 23490
:
FileName /000225.sst, size 23490
FileName /000226.sst, size 23496
FileName /000227.sst, size 23493
FileName /000228.sst, size 23498
FileName /000229.sst, size 23487
FileName /000230.sst, size 23495
FileName /000231.sst, size 18966

I do see that files eventually get compacted if and when there are subsequent writes to the db with auto compaction in both good and bad cases.

Attached is the patch file with actual test case used (can be applied through 'git am')
[0001-New-test-case-for-Dynamic-level-compaction-v4.diff.txt](https://github.com/facebook/rocksdb/files/4132502/0001-New-test-case-for-Dynamic-level-compaction-v4.diff.txt)

cc:
@deepakojha123

@ajkr
@miasantreble