This commit represents a complete refactoring of rffmpeg while
preserving all existing functionality.
Several key changes are:
1. A cleaner function tree throughout the code, hopefully making things
easier to understand.
2. The use of "-t -t" to the "ssh" command to optimize behaviour when
Ctrl+C is used to terminate a test process.
3. The removal of the old PID-based "state" system in favour of a
ground-up SQLite-based system which can better track the current status.
4. The renaming of the binary from "rffmpeg.py" to "rffmpeg".
5. The addition of an alternate invocation and corresponding Click-based
CLI interface to manage the database, accessible by calling the
"rffmpeg" binary name directly instead of an "ffmpeg"/"ffprobe" alias.
6. The moving of host management out of the config file and into the
database/Click CLI interface for better management capabilities.
7. The proper defaulting of the configuration; an entirely empty
configuration can be specified if desired, using only default options.
This new version should be functionally identical to the old version in
all cases while providing the above changes.
This commit also adjust the documentation to reflect the updated setup
and options.
Adds an optional new configuration format under the remote hosts
configuration segment, allowing the specification of a weight in
addition to the host name.
Weights are used to refactor the active "count" of a host in order to
bring it lower by the following logic:
1. If a host's weight is not specified, it is 1.
2. If a host's weight is 1, its "weighted_count" is equal to its
"count".
3. If a host's weight is greater than 1, its "weighted_count" is equal
to the floor division of its real "count" and its "weight".
So for example, if there are 2 hosts with weights 1 and 2, and there is
currently 1 process running against each, the "weighted_count"s would
be:
host1: 1
host2: 1//2 = 0
And thus host2 would be considered the "least loaded" host. Then, if
another process started:
host1: 1
host2: 2//2 = 1
Resulting in the last host on the list (the first to run a process)
getting the next one, and so on.
This logic should make sense, but I cannot extensively test it.
Closes#8 aspect 1 (aspect 2 is out-of-scope)
