Add stringer to warp types

[aaronbuchwald]

Why this should be merged

This PR implements fmt.Stringer on each of the warp message/signature types including Message, UnsignedMessage, BitSetSignature, and the Signature interface.

How this works

This adds a String() function to each of the interfaces following the <type>(key1 = val1, key2 = val2, ...) string format from the consensus instance stringer functions (with the exception of Message which omits the keys since both the UnsignedMessage and Signature already include their own types).

How this was tested

Tested with one-off unit tests to see the output (not worth including in source imo):

UnsignedMessage(NetworkID = 10, SourceChainID = PsaHUQPC3dkNPNvSbteyEjC9jrg8UZfMbBadDM9QhSrd3pvAT, Payload = 7061796c6f6164)
BitSetSignature(Signers = 0000000000000000, Signature = 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)
WarpMessage(UnsignedMessage(NetworkID = 10, SourceChainID = TtF4d2QWbk5vzQGTEPrN48x6vwgAoAmKQ9cbp79inpQmcRKES, Payload = ), BitSetSignature(Signers = , Signature = 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000))

[StephenButtolph]

All of the other functions are defined on the pointers... I think these should be too. Aside from that lgtm

[aaronbuchwald]

All of the other functions are defined on the pointers... I think these should be too. Aside from that lgtm

This was intentional since the string function doesn't modify the values, so there's no need for them to take a pointer receiver. Also, the Message type has an UnsignedMessage value field instead of a pointer, so the alternative was to take a reference to that in its String() function, which is fine, I just slightly preferred defining the function on the value.

Lmk if you still prefer changing these functions to use the pointer receiver and I'll update it and the reference in Message's String() function.

[StephenButtolph]

This was intentional since the string function doesn't modify the values, so there's no need for them to take a pointer receiver. Also, the Message type has an UnsignedMessage value field instead of a pointer, so the alternative was to take a reference to that in its String() function, which is fine, I just slightly preferred defining the function on the value.

Lmk if you still prefer changing these functions to use the pointer receiver and I'll update it and the reference in Message's String() function.

The main 2 reasons I feel like it should be on the pointer type are:

• Users are normally going to hold the pointer type (because we expect/return a pointer to these structs everywhere we expose them)
  • NewUnsignedMessage
  • ParseUnsignedMessage
  • NewMessage
  • ParseMessage
    All take in/return pointers ^
• Consistency

I'd like them to be pointer receivers unless you feel strongly against it.

[aaronbuchwald]

This was intentional since the string function doesn't modify the values, so there's no need for them to take a pointer receiver. Also, the Message type has an UnsignedMessage value field instead of a pointer, so the alternative was to take a reference to that in its String() function, which is fine, I just slightly preferred defining the function on the value.
Lmk if you still prefer changing these functions to use the pointer receiver and I'll update it and the reference in Message's String() function.

The main 2 reasons I feel like it should be on the pointer type are:

• Users are normally going to hold the pointer type (because we expect/return a pointer to these structs everywhere we expose them)

  • NewUnsignedMessage
  • ParseUnsignedMessage
  • NewMessage
  • ParseMessage
    All take in/return pointers ^

• Consistency

I'd like them to be pointer receivers unless you feel strongly against it.

Yup, just updated