Allow upgradable contracts to inherit directly from EternalStorage

[cwhinfrey]

• Make EternalStorageProxy inherit from EternalStorage first
• Remove OwnedUpgradeabilityStorage

Switching EternalStorageProxy to inherit from EternalStorage before OwnedUpgradeabilityProxy makes the EternalStorage state come first. This allows upgradable smart contracts (like Token_V0 in the example) to inherit directly from EternalStorage instead of OwnedUpgradeabilityStorage and completely eliminates the need for OwnedUpgradeabilityStorage. OwnedUpgradeabilityStorage was necessary to make sure the EternalStorage state was in the right memory slots but if no state comes before the EternalStorage state, it is not necessary.

[AugustoL]

:clap: :clap: @cwhinfrey . I think you will need to change the diagram of the implementation in the docs too and remove the OwnedUpgradeabilityStorage too, right?

[cwhinfrey]

👍 @AugustoL I'll get that updated

[cwhinfrey]

@AugustoL I update the docs. Let me know if it makes sense. (Also, didn't mean to close the PR a little bit ago)

[facuspagnuolo]

In this case we are breaking the idea of having a Token_V0 that follows exactly the same storage structure needed by the proxy, am I right? I mean, it won't be aware of the upgradeabilityProxyOwner, right?

[cwhinfrey]

@facuspagnuolo Right, the storage structure would be the same for the EternalStorage state variables but Token_V0 functionality would not be aware of _upgradeabilityOwner, _version, and _implementation unless it also inherited from UpgradeabilityOwnerStorage and UpgradeabilityStorage. My thinking was that typically contracts like Token_V0 are only interacting EternalStorage state variables and that the state and functionality from UpgradeabilityOwnerStorage and UpgradeabilityStorage was unnecessary for contracts like Token_V0.

[rstormsf]

I think it's the right way of doing it

[facuspagnuolo]

Oh, I see.. Looking at the readme diagram it wasn't clear that you were changing the storage structure of the EternalStorageProxy too, nice catch! Given that left-to-right order in the diagram was intended, we should flip the readme diagram to reflect how EternalStorageProxy's inheritance structure works now.

[cwhinfrey]

@facuspagnuolo Good point. Just updated the readme diagram to reflect the inheritance structure.

[facuspagnuolo]

@cwhinfrey please indent the readme diagram two more spaces to the right, otherwise it won't be interpreted as a block code and the result will be the following:

Thanks!

[cwhinfrey]

@facuspagnuolo updated 😃