Minor Optimization: Keep track of recently rejected transactions

[davecgh]

Currently, when a transaction is rejected, it simply responds to the peer with the appropriate reject message and does not keep track of the fact it has been rejected. This behavior is accurate, but it could be optimized by keeping track of recently-rejected transactions since the same transaction might be coming from multiple peers if it was rejected for being considered non-standard as opposed to being invalid.

By keeping a small map of recently rejected transactions along with the reject reason/message, there would only need to be one database lookup and associated validation even if the same transaction shows up from multiple peers. This map would obviously need to be size-limited and provide random eviction and replacement once the limit is reached (just like the existing mruinvmap).

[dajohi]

I think this can be closed @davecgh