feat: add era to blocks/{blockId} response for extrinsics

[TarikGul]

closes: #486

This adds the era field. @joepetrowski .

The era enum has two possibilities, immortalEra, and mortalEra. Example return values for each:

era: {"immortalEra": "0x00"}
era: {"mortalEra": ["64", "11"]}

Todo:

• Update e2e-tests
  • kusama
  • polkadot
  • westend (Under the exception 2 tests are failing but they are unrelated to this PR)
• Update unit tests

[dvdplm]

Hmm, this is a bit dense to parse. Is this correct? The first parameter, 64 in the example, is the Period and indicates the number of blocks for which the extrinsic is valid, starting from the block the extrinsic was signed? But what is the Phase? The wording "The Phase is the period" is confusing to me!

[jsdw]

This always confuses me in the documentation too. I assumed a mortal era was just a block number, and a number of blocks it'd be valid from after that (and the signature material contains the block hash so we can verify that the block numbered is what you'd expect), but I don't think I'm quite right (I'm not sure what a "phase" is)?!

[jsdw]

(to build on this; iirc we don't pass a block hash at all in the transaction; we just sign it against a block hash, so you need to know the block number you'll be getting the hash of to verify the signature I think?)

[joepetrowski]

Yes, the runtime keeps a mapping of BlockNumber => BlockHash for the last BlockHashCount blocks: https://github.com/paritytech/polkadot/blob/v0.9.10/runtime/common/src/lib.rs#L81

The mortality is a number of blocks, but it's encoded in one byte, so it's 2 ** mortality. Front ends abstract this by letting you "choose" a validity period, but if you choose e.g. 50 blocks it would actually be mortal for 64.

[dvdplm]

If I understand this correctly, this is the only possible value for the immortal case? So rather than a default, it's just the hard coded value that must be there for Reasons™? If that is correct, can we get rid of it somehow, and have just immortalEra?

[TarikGul]

Yes totally, correct. I agree it should just be immortalEra in this case. A description explaining that the value is hardcoded or will always be '0x00' would possibly suffice?

[jsdw]

One way to represent the return types I guess could be:

era: {
   type: "immortal"
}

or

era: {
   type: "mortal",
   period: 64,
   phase: 12
}

(with a typescript type like { type: "immortal" } | { type: "mortal", period: number, phase: number }. I'm pretty sure that can be represented in openAPI as well but I'd have to remind myself how!)

[dvdplm]

A description explaining that the value is hardcoded or will always be '0x00' would possibly suffice?

That's ok for this PR. Perhaps add an issue to investigate James' suggestion?

[TarikGul]

Sweet, so I added a concise description for immortal -> Hardcoded constant '0x00'. I do like the idea of the return type being as @jsdw put it. The one reason I like it is the natural response from substrate has mortal being iterable, and immortal just being a string. Having different data structures in the same response field is a little odd for our circumstances.

I do think for now it might be wise to keep the response as close to substrate as possible. The idea being if anything were to change in substrate (low likely hood), the little logic there is for getting era wont change.

[TarikGul]

Merging