Fix the connectblockslow testvector generator script to be deterministic.

[nathan-at-least]

In this PR review @bitcartel determined that he could not reproduce the same hash for the connectblockslow testvector that @str4d created.

We timeboxed fixing that non-determinism and hit the time limit, and decided to deploy with a 'baked in' non-deterministic testvector for the time being.

The purpose of this ticket is to fix that non-determinism so that anyone can recreate the same benchmark on identical data. After that is done, we should measure that against today's 'special instance' of the test vector to ensure there's no performance difference, then update our benchmarking system to use the deterministic dataset.

This is important for a variety of reasons. One is to detect regressions in the determinism itself, as well as to ensure repeatability of measurements.

[str4d]

@bitcartel sent me the archive he made, and the non-determinism is obvious:

$ diffoscope block-107134-str4d.tar.gz block-107134-bitcartel.tar.gz 
 |################################################################################################################|  100%                             Time: 0:00:00 
--- block-107134-str4d.tar.gz
+++ block-107134-bitcartel.tar.gz
│   --- block-107134-str4d.tar
├── +++ block-107134-bitcartel.tar
├── file list
│ │ @@ -1,7 +1,7 @@
│ │ -drwxrwxr-x   0 str4d     (1000) str4d     (1000)        0 2017-05-17 00:00:00.000000 benchmark/
│ │ -drwxr-xr-x   0 str4d     (1000) str4d     (1000)        0 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/
│ │ --rw-r--r--   0 str4d     (1000) str4d     (1000)        0 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/LOCK
│ │ --rw-rw-r--   0 str4d     (1000) str4d     (1000)       50 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/MANIFEST-000002
│ │ --rw-rw-r--   0 str4d     (1000) str4d     (1000)       16 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/CURRENT
│ │ --rw-rw-r--   0 str4d     (1000) str4d     (1000)  1170023 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/000003.log
│ │ --rw-rw-r--   0 str4d     (1000) str4d     (1000)  1996220 2017-05-17 00:00:00.000000 benchmark/block-107134.dat
│ │ +drwxr-xr-x   0 bitcartel   (1000) bitcartel   (1000)        0 2017-05-17 00:00:00.000000 benchmark/
│ │ +-rw-r--r--   0 bitcartel   (1000) bitcartel   (1000)  1996220 2017-05-17 00:00:00.000000 benchmark/block-107134.dat
│ │ +drwxr-xr-x   0 bitcartel   (1000) bitcartel   (1000)        0 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/
│ │ +-rw-r--r--   0 bitcartel   (1000) bitcartel   (1000)       16 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/CURRENT
│ │ +-rw-r--r--   0 bitcartel   (1000) bitcartel   (1000)        0 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/LOCK
│ │ +-rw-r--r--   0 bitcartel   (1000) bitcartel   (1000)       50 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/MANIFEST-000002
│ │ +-rw-r--r--   0 bitcartel   (1000) bitcartel   (1000)  1170023 2017-05-17 00:00:00.000000 benchmark/block-107134-inputs/000003.log

The owner and group can easily be made deterministic with that tar flags --owner=NAME and --group=NAME. The directory listing order might take a bit more work.

[str4d]

Looked at how the Gitian descriptors do it - find | sort | tar | gzip.