Accountable pruning procedure for fungible assets schema (RGB-20)

[dr-orlovsky]

Pruning procedure is a proposed mechanism for truncating amount of data clients need store for their assets history (and pass between them during asset transfer). The currently considered procedure for fungible asset schema allows an issuer to produce a new set of assets outside of a secondary issue process, and other parties should trust it that this assets are backed by some previously burned issued assets. @afilini pointed out in #20 that this is actually a "trick" that may allow shadowed secondary issuance for dishonest issuers and proposed to merge pruning and secondary issuance . Here I propose another workflow for asset history pruning with (eventual) provable protection from pruning misuse.

With the proposed procedure we define two types of seals: epoch and prune. Each issuance (primary and secondary) must have at most one epoch seal defined (with empty/no/void associated state); where the absence of an epoch seal will mean that pruning for this issuance is not supported. An epoch seal may be closed over a state transition of special type "epoch" (epoch transition), which may define a seal for the next epoch plus multiple prune seals, which will work as was planned before.

This will split pruning process into a pruning epochs, such that the amount of assets that was pruned may be tracked: any asset may be pruned within an epoch only once; and all users may track how much assets were pruned out of the issued supply. This will lead to the eventual consistency: once all of the issue was pruned, users will see that no new assets were produced by the issuer.