MASP first epoch rewards in client

[grarco]

MASP rewards are given out at every epoch for eligible assets tagged with the previous epoch, so that when the protocol switches to MASP epoch x it generates conversions for assets from epoch x-1 to x.

The client decides wether to decorate an asset with an epoch or not based on its presence in the conversion tree. So it will start attaching an epoch only after the first conversion for that asset has been produced. If a new asset is added to the reward program it will first be added to the token map and the first conversion will happen at the next MASP epoch switch. Since the token is not yet present in the conversion tree, the client won't attach any epoch when producing shielding transactions, meaning that, at the next masp epoch, none of these tokens will be entitled rewards.

To improve on this we could have the client look at the token map instead of searching the conversion tree: the presence of the asset in the map means that at the next MASP epoch we'll produce a new conversion for it and so we should attach the current MASP epoch to it to be entitled those rewards. Also, if the token is not in the token map (even if it is in the conversion tree), it means that at the next MASP epoch we will not produce a conversion for it and so there's no need to attach an epoch.

Unfortunately, if the governance proposal enabling masp reward for the given token is executed at a MASP epoch change this solution won't work: in this scenario we should rely on a more refined logic involving the analysis of ongoing governance proposals.