/sign endpoint

[aphelionz]

This is required for https://github.com/flow-hydraulics/fcl-wallet-adapter. The requirement is simply an endpoint that takes a built transaction and a custodial account ID as an input and outputs the proper signature.

Here's more context:

Upon approval, the FCL adapter frontend should submit the transaction to the adapter backend, which in turn passes it to the Wallet API for signing.
This sign endpoint can be fully trusted. That means that it will not validate transactions before signing, and can even take a simple byte array (e.g. hex string as input).

[tuommaki]

I'm currently working on this task, but would like to get clarification to couple details on this.

As I currently understand this, the endpoint should receive transaction details, accompanied with the account details and then construct the transaction object, compute the signatures and return them, but not send the transaction just yet.

Therefore this differs from existing transaction creation operation which doesn't sign it, but does send it nevertheless.

1. Should the request input structure of this endpoint look similar to that raw transaction sending?
2. How are proposer and authorizer[s] passed in?
3. How should the response structure look like? Should it contain the whole transaction with authorization and payment envelopes, or only the signatures? If only signatures, should it still contain both of them?
4. As I understand it, the payer is always the admin account, but besides that, should there be any defaulting for possibly missing account addresses in input request?

Ping @psiemens