Define different structs for different asset types

[alexdewar]

This came up in a conversation with @Aurashk ages ago and I thought it was a good idea, but haven't got round to opening a discussion about it until now.

At present, we have a single Asset struct which encompasses all kinds of assets whether candidates, commissioned, decommissioned etc. These different kinds of asset have slightly different state, with some commonalities, with certain fields that only apply to certain kinds residing inside a state field (using the AssetState enum). This struct is most commonly used via the AssetRef wrapper, which provides a ref-counted reference to an Asset as long as some additional methods.

The advantage of this approach is it means that you can pass around assets of different kinds just using the Asset struct (or AssetRef... but note that this is also a disadvantage! It means, for example, that if you want to write a function that only accepts assets whose state is Commissioned, then you have to just accept the generic Asset type as an arg and assert! its state later. You also end up calling unwrap() for properties you know will be present (e.g. agent ID). This all smells like an anti-pattern.

There are places where we group assets of dissimilar kinds together that would have to be changed (e.g. we internally store Commissioned and Candidate assets in the variable map for dispatch), but, for many of these cases, it may result in clearer code (e.g. if we separate out the already-commissioned assets from the selected candidates during appraisal). Note that we can still have places in the code where different types of assets are accepted (function arguments, in collections etc.), but we would need to come up with another solution, such as using traits based on common functionality or enums (e.g. a DispatchableAsset one for candidates/commissioned). Again, while these are friction points, I think the solution could end up being clearer than the current code.

I don't think we should do this in one swoop. Instead, I think this could be an idea about how we want the asset code to look in the long term and we could gradually remove AssetState variants one by one. As a starting point, we will probably have to get rid of the Decommissinoned variant anyway when we do #1245. The Parent variant will be removed for #1123. We could easily remove the Future variant without impacting much of the rest of the code. The more fiddly bit will be the dispatch and investment code, but, as I've mentioned, I think the end result will be cleaner and the effort will be worth it.