Resolved circular dependencies between delegatebw, voteproducer, and buyrex.

[aaroncox]

There's some non ideal conditions currently for new accounts looking to stake tokens in the REX pool and be rewarded their share of the network fees. Imagine the following use case for an EOSIO token under the current EOSIO contracts:

A brand new user has just purchased the tokens from an exchange, created an account, and wants to park them in REX to earn a passive return. The user withdraws their tokens from the exchange to their new account. This account now has an available token balance, is voting for no producers, and has no tokens staked to either CPU or NET.

This new account cannot currently put tokens into REX until they stake to either CPU or NET first. The reason for this is:

1. In order to perform the buyrex action, an account must be voting for block producers.
2. In order to perform the voteproducer action, an account must have either a staked balance or balance in REX.

The only way for this account to be eligible to perform the buyrex action is to first perform the voteproducer action, and the only way they will be able to perform the voteproducer action is if they first perform the delegatebw action to their own account and stake tokens to either CPU or NET.

Currently in order for a new account to participate in REX, they will need to perform the following actions (which can be bundled into a single transaction):

• delegatebw: Stake 0.0001 to either CPU or NET.
• voteproducer: Vote for individual producers or a proxy.
• deposit: Deposit the user's desired balance minus the 0.0001 for staking.
• buyrex: Use the deposited tokens in order to convert to REX.

An example of this all being bundled together can be found here:

https://www.bloks.io/transaction/d41132d44b38b3f33a74108e2d09c60097d1d2e181116dc2754ed341049388ce

This creates friction in how a user has to participate in REX. Some won't notice the 0.0001 being staked, but those who do will be slightly confused. Explaining this required step will also be somewhat confusing. It also utilizes more RAM than needed due to the delegatebw action we are forced to perform to complete this process.

The goal here should be to remove the circular dependency between voteproducer and buyrex. One potential solution could be to remove the staking/rex requirements when voting producers. This would allow the account to perform the voteproducer + deposit + buyrex actions without requiring the initial delegatebw action.