Try catch authorization (alternative 1)

[MerlinEgalite]

Fixes #46

[pakim249CAL]

I'm not convinced that skipping the revert is a good idea in the bulker. For example, if there were two bulk transactions like this in the mem pool:

1.1. Set authorization to true
1.2. actions
1.3. Set authorization to false

2.1. Set authorization to true
2.2. actions
2.3. Set authorization to false

Then if 1.1 if frontrun, the second set of tx should probably revert. But it would not with this implementation.

[MerlinEgalite]

I'm not sure I understood the pb. Why would I submit 2 bundles at the same time? Missclicked?

[pakim249CAL]

If there is no perceived problem with this by the team, then I'm okay letting it go. But I think it's important to point out that this kind of behavior could happen, and the code would not operate as intended under circumstances in which multiple sets of transactions are in the mem pool.

[MerlinEgalite]

If we don't do that then you could prevent an entire bundle from happening by frontrunning the tx. I'd say this problem seems more likely to occur than the one you mentioned but I might be wrong tbh

[pakim249CAL]

Yes, I agree that it is more likely that the tx gets frontrun. However, I think that signatures being frontrun and having the tx revert is a much lower severity problem than unintended interactions NOT reverting. I'm not entirely sure what attack vectors exist from the problem I point out, but the problem of a frontrun signature is much easier to define. Just something to consider.