Add tenure_extend_timestamp to Block Response Accept messages

[jferrant]

Needed to complete #5434

[jferrant]

Changed this to make config to str test pass.

[hstove]

This needs to be backwards compatible - right now it'll fail if the payload doesn't have the timestamp. I think there's already a unit test with fixtures for backwards compatibility

[jferrant]

This needs to be backwards compatible - right now it'll fail if the payload doesn't have the timestamp. I think there's already a unit test with fixtures for backwards compatibility

I mean I can easily make this default fill the timestamp with u64::MAX if not found. Not sure that is considered backwards compatible enough. I don't actually see why this has to be backwards compatible though. It would of course require signers to upgrade, by why does this need to be backwards compatible? (I just assumed not required as we do not back process Block Responses nor do we store them anywhere internally in the signers DB....EDIT: I think I just answered my question though. miners would have issues.)

[obycode]

I don't actually see why this has to be backwards compatible though.

Since we are doing this without a hard fork, miners that upgrade should be able to talk to signers that have not upgraded, and vice versa.

[jferrant]

I don't actually see why this has to be backwards compatible though.

Since we are doing this without a hard fork, miners that upgrade should be able to talk to signers that have not upgraded, and vice versa.

haha I just answered this in my own response to Hank right before I saw this XD

[hstove]

LGTM! Should we merge this into a broader feature branch? This PR itself is probably fine to merge into develop, but with other PRs we'll probably want some other base branch.