fix: Return non-zero value for burn_block_time in v1 API

[jbencin]

Description

API endpoints extended/v1/block and extended/v1/block were empty/zero values for the following variables:

{
      "burn_block_time": 0,
      "burn_block_time_iso": "",
      "parent_burn_block_time": 0,
      "parent_burn_block_time_iso": ""
}

This was due to failing to parse and store the timestamp from the burnchain block in StacksSubnetBlock::from_new_block_event(). This PR fixes this issue so that these variables are now proper Unix and ISO-8601 timestamps:

{
      "burn_block_time": 1679512099,
      "burn_block_time_iso": "2023-03-22T19:08:19.000Z",
      "parent_burn_block_time": 1679512039,
      "parent_burn_block_time_iso": "2023-03-22T19:07:19.000Z",
}

Applicable issues

• fixes Fix timestamps #239

Additional info (benefits, drawbacks, caveats)

We still report 0 for genesis block. Not sure if that's a problem

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[codecov]

Codecov Report

Merging #243 (61276de) into master (542dc5e) will increase coverage by 93.47%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master     #243       +/-   ##
===========================================
+ Coverage        0   93.47%   +93.47%     
===========================================
  Files           0        6        +6     
  Lines           0      337      +337     
===========================================
+ Hits            0      315      +315     
- Misses          0       22       +22     

see 6 files with indirect coverage changes

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

[obycode]

LGTM. Thanks @jbencin!