Remove many fields from ChallengeRegistered event

[geoknee]

Towards #1588

Justifications:

turnNumRecord -- this is always the turn num of the candidate (emitted)

isFinal -- again this is already emitted in the candidate state

fixedPart: I think it is safe to assume off chain clients have this already, if they are "interested in" this channel id

We can go further

The finalizesAt is easily computable by the event block timestamp plus the challenge duration in the fixed part. Only thing is, we will need to go back to the Ethereum JSON API to get the block timestamp from the blocknumber. If we were using block number- based challenge durations, this problem would go away.

If we are happy to claw information back from the calldata of the transaction causing the event, we probably don't need to re-emit candidate and proof.

These ideas can be the subject of future PRs.

[netlify]

✅ Deploy Preview for nitro-gui canceled.

Name	Link
🔨 Latest commit	37921eb
🔍 Latest deploy log	https://app.netlify.com/sites/nitro-gui/deploys/64e8e8258911260008c75a51

[netlify]

✅ Deploy Preview for nitro-storybook canceled.

Name	Link
🔨 Latest commit	37921eb
🔍 Latest deploy log	https://app.netlify.com/sites/nitro-storybook/deploys/64e8e825e82cd800070043aa

[netlify]

👷 Deploy Preview for nitrodocs processing.

Name	Link
🔨 Latest commit	37921eb
🔍 Latest deploy log	https://app.netlify.com/sites/nitrodocs/deploys/64e8e825c6d4730008ab21c8

[lalexgap]

If we are happy to claw information back from the calldata of the transaction causing the event, we probably don't need to re-emit candidate and proof.

In theory I think we could just emit a challenge event with the channelId to alert someone a challenge has occurred and the rest of the information could be parsed from the challenge call data. I think you could even avoid events all together by just monitoring blocks for transactions to the adjudicator; although this would be a lot less efficient since you can't utilize the log bloom.