Implement utility traits for tendermint data types

[yihuang]

I removed the Default instances that don't make sense.

[yihuang]

• Removed Default instance for Account::Id, PublicKey, validator::Info (I must have missed that).
• Fixed Time format to use .to_rfc3339_opts(SecondsFormat::Micros, true)

[tarcieri]

I don't think an all-zero hash or a default time makes sense. The rest looks fine.

[yihuang]

I've changed the format of Time to SecondsFormat::Nanos, according to tendermint implementation.

[tarcieri]

Perhaps I'm a bit jaded by (in some cases security) vulnerabilities relating to Go zero values, which it seems is how Default is being leveraged in the cases I pointed out in this review.

If you're looking for a way to easily construct test fixtures, I think Default is the wrong tool for the job. Alternatively, in the test suite itself, you can define a trait specifically for test fixtures in the test suite itself, and then impl it however you want!

trait TestFixture {
    fn test_fixture() -> Self;
}

impl TestFixture for Hash {
    fn test_fixture() -> Hash {
        Hash::Null
    }
}

In general, I think it's a bad idea for anything that's a testing-related convenience to leak outside of the test context, especially when it could potentially lead to security issues in production.

Is that what most of these are for?

[yihuang]

Perhaps I'm a bit jaded by (in some cases security) vulnerabilities relating to Go zero values, which it seems is how Default is being leveraged in the cases I pointed out in this review.

If you're looking for a way to easily construct test fixtures, I think Default is the wrong tool for the job. Alternatively, in the test suite itself, you can define a trait specifically for test fixtures in the test suite itself, and then impl it however you want!

trait TestFixture {
    fn test_fixture() -> Self;
}

impl TestFixture for Hash {
    fn test_fixture() -> Hash {
        Hash::Null
    }
}

In general, I think it's a bad idea for anything that's a testing-related convenience to leak outside of the test context, especially when it could potentially lead to security issues in production.

Is that what most of these are for?

Yeah, actually we've changed the test code to use more properly constructed mocking data now.
But what's left in this patch now IMO are quite reasonable ;D

[tarcieri]

@yihuang looks like this needs a GPG signature

[yihuang]

@yihuang looks like this needs a GPG signature

Done.