accounts/abi/bind: allow to specify signer on transactOpts

[MariusVanDerWijden]

This commit enables users to specify which signer they want to use while creating their transactOpts.
Previously all contract interactions used the homestead signer. Now a user can specify whether they
want to sign with homestead or EIP155 and specify the chainID which adds another layer of security.

closes #16484

This PR changes the interface of New{}Transactor, so it is a breaking change for everyone who uses the bind package to create their signer.

[karalabe]

Wondering if we should use a chainid instead of a signer as a new parameter? The auth package is mostly a convenience thing so you don't need to construct your transactor manually and so you don't need to care about the details. It seems sane to me to explicitly enforce EIP155 in a convenience method and let the user do the manual dance if they want he unsecure version. It's also easier to tell the users to pass the chainid, than to "construct an EIP155 signer".

What are your thoughts? I'm open to alternatives, just looking at it from an API perspective.

Also this PR would break all existing code relying on abigen generated contracts :P

[MariusVanDerWijden]

Yeah I think that might be a better interface, we don't really want to encourage homestead signers anymore, right?
I'll change it to use ChainID and eip155 signers.
About breaking all existing contracts: Yeah but I think the change might be so useful that it outweighs the inconveniences.
Only problem I can see is that Dapp developers have to introduce a global variable to identify the network, default it to 1 and set it to 1337 in testing. Oh btw It is not really documented that all simulated backends run chains with chainID 1337 in the source code, shall I add some docu there?

[karalabe]

The more docs the better :)

[holiman]

Makes sense to me, but I'm not really well versed in that whole abi/bind thingy, I've never used it and am not the best person to give a thumbs-up :)

[gballet]

In order not to break contracts right off the bat, It should be possible to keep the legacy system and display a deprecation warning when the function is used, and offer the new API with a slightly different name. Leave it like that for a few releases and then remove it.

[MariusVanDerWijden]

Hmm I restored the old functions now, I'm not a huge fan, but at least I'll get a purely red pr in some months

[gballet]

LGTM

[MariusVanDerWijden]

cc @fjl

[MariusVanDerWijden]

cc @fjl