Implement telemetry validation

[frol]

Story

Currently, Explorer accepts telemetry reports without validation, so anyone can submit fake information about fake nodes. Nodes that do blocks/chunks production (validation) sign their telemetry data, so we should start with validating those. The telemetry from nodes that do not validate blocks/chunks have no key that is recorded on the chain, so we cannot check if they are legit nodes or fake ones; to mitigate this we may create a contract and ask users to make a function call to register the node key. Thus, we will have:

1. telemetry that is signed with the validator_key and we require the validation nodes to have their telemetry signed with that
2. [icebox] telemetry that is signed with the node_key registered via in some contract
3. [icebox] telemetry that is not signed, which we may still include on our list, but we may decide to filter those out if we see any abuse

Useful links:

• https://github.com/near/nearcore/blob/9a41274ddef3616ab195b24a207389c5ad5c7f5a/core/primitives/src/validator_signer.rs#L163-L168

Acceptance criteria

• [ ] Legit telemetry request from a validation node should be recorded to the database
• [ ] Fake telemetry request from a "malicions" validation node should be ignored (and logged)
• [ ] Telemetry request from a non-validation nodes should be recorded as is (we don't list those in UI, so it is fine for now; see the icebox items for the ideas of how to validate those telemetry records)

[shelegdmitriy]

@frol I far as I remember this issue is blocked by serialization (or something else) so do we have any mention about it?

[frol]

This is blocked on someone thinking through how to address the issue that nearcore signs telemetry JSON text and adds the signature inside that JSON, and thus when Explorer parses JSON, extracts signature, and checks the rest of the payload with that signature, verification fails due to the serialization mismatch, e.g. the immediate problem was that nearcore serializes float numbers as 0.0 while JS serializes them as 0 and thus signature verification fails, but in the future, we might potentially have other problems when the fields are mixed in their order or formatting will be different.

It is not ideal, but it is not burning yet.