Fixing datetime tuf specification

[SequeI]

Issue #, if available:
Currently when using tuftool create or tuftool update, the created metadata will have nanoseconds within the metadata datetime.
As you can see in the official tuf specifications here, ISO 8601 is the current standard by which it is "YYYY-MM-DDTHH:MM:SSZ".

Description of changes:
Right now, the concatenated datetime object results in an unwanted nanosecond ending so in this PR any nanosecond result on the datetime object is set to 0, effectively rounding it to the nearest second so it is in line with the tuf specs.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jpculp]

Hi @SequeI, thank you for your contribution. We'll take a look!

[cbgbt]

Thanks for your contribution!

You're right, we do need to constrain the timestamp outputs here to match the spec. Rather than constrain our datetime parsing, I'd prefer if we could instead focus on controlling the serialization.

It seems like there's an example in the serde documentation for customizing the date format from chrono. We could implement a serializer and then ensure that serializable structs with inner timestamps use the correct serialization, but that seems like it would be easy to make a mistake.

Another way we could approach this would be to create a newtype wrapper around DateTime<Utc> with the desired Serialize implementation. Here's an example of what I mean implemented in the Rust playground:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=65a2c0f9ec2691bfad3daf04d9d39640

I've never tried it, but I wonder if this would combine nicely with the clippy disallowed_types lint to ensure that we prefer the wrapper instead.