Upgrade script to use usecs after timestamp upgrading timestamp logic

[l-monninger]

Summary

• RFCs: Link to RFC, Link to RFC, or $\emptyset$.
• Categories: any of protocol-units, networks, scripts, util, cicd, or misc.

#1067 changes fixes a bug that emerged from the unsuccessful marshaling of secs and usecs across upgrades. This is a downstream response to that change.

Changelog

Testing

just movement-full-node native build.setup.eth-local.celestia-local.test-bring-up-elsa-to-biarritz-rc1

Outstanding issues

[mzabaluev]

These conversions look suspicious next to TryFrom<Block>, and they were previously removed. Is it really so that a blob can encode a block, a single ID, or an array of IDs, with nothing to discriminate?
The change also does not seem to belong with the rest of the PR. A stray checkout, perhaps?

[mzabaluev]

This value seems wrongly computed now, if expiration_timestamp_sec_offset is still in seconds.

We could benefit from a Timestamp domain type with controlled conversions.

[andygolay]

@mzabaluev @l-monninger is the test command correct? When I run

 nix develop --extra-experimental-features nix-command --extra-experimental-features flakes --command bash  -c "just movement-full-node native build.setup.eth-local.celestia-local.test-bring-up-elsa-to-biarritz-rc1"

I get error: Recipe movement-full-node failed on line 6 with exit code 101

[andygolay]

@l-monninger @mzabaluev @0xmovses as far as I can tell, this is incorrect, because:

In maptos/framework/releases/elsa/src/bin/release.rs main function we have

	elsa.release(
		&local_account_release_signer,
		2_000_000,
		100,
		// 60 seconds from now as u64
		60,
		&rest_client,
	)

fn release is clearly taking as seconds for its expiration_timestamp_sec_offset param:

	fn release(
		&self,
		signer: &impl ReleaseSigner,
		max_gas_amount: u64,
		gas_unit_price: u64,
		expiration_timestamp_sec_offset: u64,
		client: &Client,

Same with in this function:

	pub async fn migrate_framework_from_elsa_to_biarritz_rc1(
		&self,
		client: &aptos_sdk::rest_client::Client,
		signer: &impl ReleaseSigner,
	) -> Result<(), ElsaToBiarritzRc1Error> {
		// todo: validate that the current release is Elsa

		// upgrade to Biarritz RC1 with the gas upgrade
		let biarritz_rc1 = BiarritzRc1::new();
		biarritz_rc1
			.release(signer, 2_000_000, 100, 60_000, client)
			.await
			.map_err(|e| ElsaToBiarritzRc1Error::MigrationFailed(e.into()))?;

		Ok(())
	}

60,000 seconds is 16.7 hours, whihc makes sense for allowing votes on the migration, if I understand it correctly.

release calls propose_release with the same params, so don't we need to change all calls of release so microseconds are passed in for expiration_timestamp_sec_offset?

I might be misunderstanding it, but yeah I seem to be resonating with Mikhail's comment: #1075 (comment)

Still looking into the details for greater certainty and best solutions. I'm not sure how easy it would be to implement the Timestamp domain type but it does seem like a good idea at face value.