Introduced callback field in PQL

[jbargu]

Currently result of the event that is processed from the A chain, will be returned to the A chain. With callback field in PQL definition we can modify this behaviour to submit the result to a different chain B. This will allow for signaling between different chains. Suppose we have a bridge between chains A <-> B. The bridge allows for sending assets between chains A and B, but does not allow calling arbitrary contract functions. The callback field could be used in this case. Suppose we want to send 100 ETH from chain A to chain B and invest it into contract '0xdeadbeef0' located on the chain B:

Chain A:

contract ChainAContract {

	ParalinkOracle oracle;
	BridgeAdapter bridge;

	function investIntoContractOnChainB(uint256 _amount, address _contractAddressChainB, address _callbackFunctionIdChainB) {
		bytes32 ipfsHash; // Includes callback field
		uint256 nonce;

		bridge.transfer(_amount, _contractAddressChainB); // we would need bridge TX ID to identify it on the other side
		oracle.request(
            ipfsHash,
            msg.sender,
            contractAddressChainB,
            callbackFunctionIdChainB,
            nonce,
            ""
        );
		// oracle.request emits Request event, which is processed by the paralink node
		// Paralink node monitors the contractAddressChainB contract on chain B for the deposit TX ID to occur.
		// When the deposit happens, the node calls `callbackFunctionIdChainB` to process the deposited assets.
		// Paralink node calls the chain A `fullfillRequest` to mark the request as done.
	}
}

Chain B:

// address 0xBb2b8038a1640196FbE3e38816F3e67Cba72D940
contract ChainBContract {

	function callback(bytes32 _data) {
		// process _data
		investAsset(amount, address);
	}
}

callback field would be similar to current eth.* calls:

"callback": {
	  "chain": "<unique ID chain>",
	  "address": "0xBb2b8038a1640196FbE3e38816F3e67Cba72D940",
	  "params": {
	      "function": "callback(bytes32)",
	      "args": ["customData"],
	  }
}

This assumes we have unique ID chains for all the possible chains. The matter should be researched more as I am sure there are some limitations that are not taken into the account.