Revisit arbitrary-send detector

[montyly]

I am not sure we should keep the arbitrary-send detector, from experience it does not give any meaningful results most of the time.

We need to find how to improve its heuristics or remove it

[Otto-AA]

Hi, I'd be curious to hear in which cases this detector reports false positives. For a different use case*, I thought about implementing nearly the same logic. Hearing that it's already rather useless for the general case lowers my expectations on this other use case 🙃 .

We need to find how to improve its heuristics

For my use case I would have also tried to exclude functions, where the destination is used in conditions or require statements, because then it is a "checked" destination and not arbitrary anymore. Could this help to filter out the false positives you have encountered?

*My use case would be the niche of frontrunning for badly designed "Puzzles". For instance, if a contract directly sends you ether you for finding the preimage of a hash, then sending the solution as a transaction would be vulnerable to frontrunning (someone else could see the solution in the transaction pool and copy it to submit it faster). While experimenting with different tools, I've realized that the arbitrary-send detector is already able to detect this vulnerable behaviour.

[AlissonRS]

Some ideas to reduce false-positives:

1. Ignore if the destination is address(this), e.g. transferFrom(user, address(this), amount). This would cover ERC3156.
2. Ignore if msg.sender === address(this), would cover delegatecall used between facets as part of EIP-2535.
3. Ignore if destination is an immutable state var (similar to arbitrary-send-eth: Don't report if destination is immutable state var #2488)