Consider removing transaction_cache in Sumeragi

[Erigara]

          @Erigara says: `i’m not sure that this will work out because we still need cloning because block contain all transactions`

this is a good point, but we have transaction_cache containing duplicates of transactions. It might still be worth to consider using Arc for that reason. On the other hand, I can hardly believe that transaction_cache in sumeragi is making any difference - especially after these changes are merged. We should remove it if possbile

Originally posted by @mversic in #3043 (comment)

[appetrosyan]

Cow?

I don't mind the transaction cache, it actually saved us in a couple of situations. Trying to remove it might reveal more undesirable behaviours, so if we can explore this, it'd be nice.

However, the implementation should utilise the redundancy; most transactions are kept in-RAM with no modifications. An Arc is on the right track, but it would be wasting cycles on a non-zero refcount. I personally think that Weak would do just as well if not better.

[SamHSmith]

transaction_cache came into existance as a way to not call into queue.rs because it was impressively slow. So if the queue was made actually good it might be fine. Queue needs to be designed keeping in mind that it will get frequently called by sumeragi requesting the same information.