Reentrancy vulnerability in MetaSwap.swap()
`MetaSwap.swap()` should have a reentrancy guard.\\nThe adapters use this general process:\\nCollect the from token (or ether) from the user.\\nExecute the trade.\\nTransfer the contract's balance of tokens (from and to) and ether to the user.\\nIf an attacker is able to reenter `swap()` before step 3, they can execute their own trade using the same tokens and get all the tokens for themselves.\\nThis is partially mitigated by the check against `amountTo` in `CommonAdapter`, but note that the `amountTo` typically allows for slippage, so it may still leave room for an attacker to siphon off some amount while still returning the required minimum to the user.\\n```\\n// Transfer remaining balance of tokenTo to sender\\nif (address(tokenTo) != Constants.ETH) {\\n    uint256 balance = tokenTo.balanceOf(address(this));\\n    require(balance >= amountTo, "INSUFFICIENT\\_AMOUNT");\\n    \\_transfer(tokenTo, balance, recipient);\\n} else {\\n```\\n\\nAs an example of how this could be exploited, 0x supports an “EIP1271Wallet” signature type, which invokes an external contract to check whether a trade is allowed. A malicious maker might front run the swap to reduce their inventory. This way, the taker is sending more of the taker asset than necessary to `MetaSwap`. The excess can be stolen by the maker during the EIP1271 call.
Use a simple reentrancy guard, such as OpenZeppelin's `ReentrancyGuard` to prevent reentrancy in `MetaSwap.swap()`. It might seem more obvious to put this check in `Spender.swap()`, but the `Spender` contract intentionally does not use any storage to avoid interference between different adapters.
```\\n// Transfer remaining balance of tokenTo to sender\\nif (address(tokenTo) != Constants.ETH) {\\n    uint256 balance = tokenTo.balanceOf(address(this));\\n    require(balance >= amountTo, "INSUFFICIENT\\_AMOUNT");\\n    \\_transfer(tokenTo, balance, recipient);\\n} else {\\n```\\n