Use consistent hash type across headers

[Manav-Aggarwal]

Overview

Closes #689

Checklist

• New and updated code has appropriate documentation
• New and updated code has new and/or updated testing
• Required CI checks are passing
• Visual proof for any user facing features like CLI or documentation updates
• Linked issues closed with keywords

[codecov-commenter]

Codecov Report

Merging #698 (bc29dce) into main (018e42a) will increase coverage by 0.16%.
The diff coverage is 91.54%.

@@            Coverage Diff             @@
##             main     #698      +/-   ##
==========================================
+ Coverage   54.59%   54.76%   +0.16%     
==========================================
  Files          52       52              
  Lines       10372    10356      -16     
==========================================
+ Hits         5663     5671       +8     
+ Misses       3840     3824      -16     
+ Partials      869      861       -8     

Impacted Files	Coverage Δ
types/header.go	6.89% <0.00%> (ø)
block/manager.go	66.08% <66.66%> (+0.74%)	⬆️
node/full_client.go	54.65% <84.61%> (ø)
conv/abci/block.go	94.33% <100.00%> (ø)
state/executor.go	69.90% <100.00%> (ø)
store/store.go	60.89% <100.00%> (ø)
types/hashing.go	100.00% <100.00%> (ø)
types/serialization.go	75.49% <100.00%> (+5.55%)	⬆️
types/state.go	92.10% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[nashqueue]

Only types [nit]

[tzdybal]

LGTM

[tuxcanfly]

I'm curious why header.Hash is not [32]byte, it seems we are changing code which was expecting an array to now expect slice instead. Would loosening this restriction have any unknown side effects, not covered by test?

[gupadhyaya]

lgtm

[Manav-Aggarwal]

I'm curious why header.Hash is not [32]byte, it seems we are changing code which was expecting an array to now expect slice instead. Would loosening this restriction have any unknown side effects, not covered by test?

Do we intend to support non-32 byte hashes in the future? @tzdybal

[tzdybal]

I'm curious why header.Hash is not [32]byte, it seems we are changing code which was expecting an array to now expect slice instead. Would loosening this restriction have any unknown side effects, not covered by test?

Most projects use []byte as it's just easier to use. Added benefit is, that this enable to use hashes of arbitrary length - and we're planning to provide some interface for custom hashing of blcks/headers.