Endpoint for signing transactions in json format

[DeRain]

Description

I'm sorry for the duplicate, but previous MR could not be reopened because HEAD was updated.

@cypherhat Answering your previous questions:

1. Have you tested with both contract deploy transactions and send ETH transactions?
2. chain_id shouldn't be an input parameter. The mount point is configured for a particular chain_id.

Answers:

1. I've tested only sending ether and smart contracts functions calls and I think we already have great API for contracts deployment (but anyway if we will make account_to field optional - it will work for contracts deployment too.
2. Good point. I've just updated the code accordingly. 👍

Motivation and Context

I'm tried common sign method, but it seems it's working only for custom data signatures. Anyway - I think we need a more developer's friendly way to sign the transaction.

The developer only needs to provide all json properties of the transaction and then he gets signed transaction in HEX format that ready to be broadcasted to Ethereum network by any convenient way. For example: Etherscan tool How to broadcast transaction via web3

How Has This Been Tested?

This is a brand new API and does not impact any existing code. I've created signed transactions and broadcasted them on Ropsten network via Etherscan publishing tool

Types of changes

• [ ] Documentation enhancement
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.

[DeRain]

@cypherhat By the way. Maybe adding send(true|false) parameter in debit,contract deploy, and erc20 transfer methods a bit against UNIX philosophy - do the one thing and do it well. And from this angle - one single signTx endpoint for signing transactions can be only one API in the application for doing only one thing - signing transactions 🤓

[cypherhat]

Oooh... you stab my heart re: the Unix philosophy. But, I do have to say, there are exceptions... but, I hear you. Let me think on it for a bit.

[DeRain]

@cypherhat Hello, Jeff. Did you have a chance to think about this MR? :)

[cypherhat]

I have thought about it. Since the capability you are asking for - signing transactions without sending them - exists, this is more a debate about design. I think that adding a send=false flag to each of the 3 transaction types that are supported reduces the sprawl of the interface. So, I am going to close this. Cheers!