@cothority/byzcoin meaningful instruction print

[nkcr]

What this PR does

This PR implements a instruction.getArranged() function on @cothority/byzcoin that returns a general-purpose JSON representation of an instruction. This representation is contract aware in the sense that arguments should have a meaningful string representation, based on each different contract.

The JSON has the following structure:

     *  {
     *      status: 0 | 1,   // Non-zero means an error occured
     *      type: "spawn|invoke|delete|UNKNOWN",
     *      contract: "config|darc|...",
     *      args: [
     *          {
     *              "name": "<NAME>",
     *              "value": "<VALUE>",    // Arg value or its summary
     *              "full": "<FULL VALUE>" // Optional. useful if the argument
     *                                     // have a very long representation.
     *          }
     *          ...
     *      ]
     *  }

This functionality is much needed for the Columbus project (blockchain browser). I suggest we include that as an experimental feature until the end of that project (January 2021), where at that point we will have a definitive structure.

Feel free to discuss, I'm open to discussion.

@ineiti's requests:

• [ ] Use an abstract class that the Beautifiers have to implement. Perhaps something like this would work: https://stackoverflow.com/questions/43723313/typescript-abstract-class-static-method-not-enforced
• [x] Give longer names to the classes, this will also avoid any name-clashing:
  • Config -> ConfigBeautify
  • Darc -> DarcBeautify
• [x] The tests should pass.
• [x] Squash the commits to have 1 or 2 commits.
• [x] add a beautifier/index.ts and import only this. That way you're free to re-arrange any files in there and the user can treat each sub-directory as a package without having to care about the files

[ineiti]

Very nice. The following parts need to be improved, however:

• programming
  • use interfaces for the classes
  • use interfaces for the data structures
  • add default clauses in the cases
  • find a better name than arrange - pretty-printer, toJSON, beautifier, printDetail, toHTML, ...
• functionality
  • add interpretation of the instance itself
  • add link suggestions to the structures

If it's not to be included anytime soon, you can Convert to draft.

[nkcr]

Thank you for the review. I addressed most of the comments:

use interfaces for the classes

I can't, as all the methods are static

functionality: ...

I'd like not to implement too much functionality at first, if that's ok I'd like to include this first iteration and add more on top of that when the use cases come along the way.

[nkcr]

@ineiti tests are passing, comments addressed. The proposed trick to use an interface doesn't work. The reason why Calypso tests are not passing is still mysterious to me, but I don't have time to investigate more. I made it pass by not using ChainConfig in config.ts.

[nkcr]

@ineiti defaults added.

[ineiti]

Just remove the UNKNOWN, and I think we're good.

[ineiti]

If you think this is ready, you can move it to R4M. If you think you'll modify it a lot during development of Columbus (which I suppose will happen), you can also teach the student to use a branch of cothority for his development.