Support passing array of private keys, or single private key to "signTransaction()" method

[robertdavid010]

Currently the signTransaction() method uses rest parameters to get an array of private keys to be used for signing transaction inputs.

The method expects a corresponding private key for every transaction input at the same array index. However, since the rest parameter collects unassigned parameters into an array, it is not possible to dynamically/programatically set the number of private keys passed to the method.

https://github.com/bigchaindb/js-bigchaindb-driver/blob/master/src/transaction.js#L239

static signTransaction(transaction, ...privateKeys) {
    ...
    signedTx.inputs.forEach((input, index) => {
        const privateKey = privateKeys[index]
        ...
    }
}

Suggested improvement would be to support passing an array of private keys, as well as defaulting to using only the first private key, if only one is passed, to sign all inputs.

[future-is-present]

@robertdavid010 thanks for creating the issue! I am not sure if we should support passing an array of private keys. Technically is possible but I don't think that is a good practice to have several private keys (from different entities) and sign the transaction at once. The correct way would be that each entity that has a private key to sign his/her inputs and then sends it to the next entity.

[robertdavid010]

This does not cover very well the case of spending multiple outputs/deposits of singular divisible assets from a single address. Regardless of use case, the inability to programmatically define the attributes corresponding to the tx inputs array means you have to write limited output transactions, and chain them? This enforcing of a pattern of use through limiting the method itself is extremely restrictive to even the basic use case of transfer of simple assets using multiple, but a non-derministic number of inputs.

At the very least to support the spending of inevitable "dust" caused by UTXO model, the method should support signing of all inputs with a single private key, since that is the most likely scenario in which you want to be able to support a non-deterministic number of inputs, and yet not support the pattern of sending multiple private keys to a single transaction.

Also its an easy but sloppy work around to currently support this (add 100+ attributes of the same private key to the method call)