Refactor bandwidth to use common bandwidth

[afalaleev]

We have an intention to give possibility for users to use bandwidth of smart-contract.

In this case an application can invite new users, give them possibility to use bandwidth of application, and don't pay for their creation.

In this case all limitation of users will be on smart contact level.

[s-medvedev]

Based on the analysis of the eosio code, different mechanisms are used to account for memory usage and cpu/net bandwidth.

Requirements:
The following requirements are imposed on the mechanism for the providing of cpu/net bandwidth for transaction execution by another account:

1. it's need to implement the ability to specify in the transaction an account (the owner of the application) that provides cpu/net bandwidth for this transaction (bandwidth provider later). Now, to execute a transaction, the bandwidth of all actors from all actions that are part of the transaction is used
2. it is desirable to enable the bandwidth provider account to specify what rights are needed to use its bandwich
3. it's need be able to provide bandwidth to perform an action not provided by the application (for example, transferring funds to an application account). However, not all actions can be allowed from the application's point of view (for example, transfer of funds between users). Accordingly, it's need to give the bandwidth provider the ability to choose for which actions to provide bandwidth.
4. A transaction may involve several actions (not necessarily related to the execution of actions in one application). Therefore, the bandwidth provider must be able to influence the transaction authorization process.
5. it is desirable to allow users to perform some actions (for example, implemented by the application) without the need to obtain a signature from the bandwidth provider.

Possible solutions:

1. Add to the transaction field that specifies a bandwidth provider
   • (-) this requires changing the format of the transaction
   • (-) this requires changing the code that forms and verifies the necessary signatures
   • (-) It is necessary to implement its own mechanism for verifying the sufficiency of rights
2. use transaction_extension field in transaction
   • (+) there is no need to change the transaction format
   • (-) this field is not used yet and in the future there may be problems when merging the code
   • (-) this requires changing the code that forms and verifies the necessary signatures
   • (-) It is necessary to implement its own mechanism for verifying the sufficiency of rights
3. implementation of an action for a system contract
   • (-) the providing of bandwidth is essentially an extension of the transaction, rather than some action
   • (+) there is no need to change the transaction format
   • (+) there is no need to change the code that forms and verifies the necessary signatures
   • (+) a standard mechanism is used to verify the sufficiency of rights (the bandwidth provider is required to specify the minimum privileges to perform an action using cleos set action permission)