[N12] Potential reentrancies

[cylon56]

In the codebase, we found two places where reentrancy can occur. However, those do not pose any security issue or concern but awareness should be raised:

• The invoke function of the Bulker contract can be re-entered.
• The doTransferIn function of the Comet contract is often executed at the very beginning of executions, being it an anti-pattern to follow against reentrancy.

To improve clarity, consider either reducing the attack surface by making those functions non-reentrant or clearly stating this risk in the docstrings.

[scott-silver]

@cylon56 for doTransferIn, you'd want to reverse the normal logic of checks-effects-interactions, right?

for example, in supplyBase, we start by doing the transfer in of base tokens from the from address. this transfer is the opportunity for a malicious token to attempt to take some action/alter some state in a way that we do not intend.

after the transfer, we accrue, update balances, etc, doing all the required checks along the way and reverting if we discover that we're in some unexpected/undesirable state.

this ordering is intentional. if we did it the opposite way, then it would allow the transferIn to take a reentrant action after all of our other checks had run. this seems like it would have a greater potential of allowing a malicious token to take an unexpected action, no?