Change int64 nanoseconds to timestamppb in proto messages

[aarongable]

We have lots of proto messages with fields like this:

boulder/sa/proto/sa.proto

Lines 197 to 202 in 66a4c11

	message AddSerialRequest {
	int64 regID = 1;
	string serial = 2;
	int64 created = 3; // Unix timestamp (nanoseconds)
	int64 expires = 4; // Unix timestamp (nanoseconds)
	}

Those int64s are nanoseconds since the unix epoch, which is so unclear that we have to comment it in every single proto file. Clients have to produce them with

boulder/ca/ca.go

Line 187 in 66a4c11

nowNanos := ca.clk.Now().UnixNano()

and servers have to parse them with

boulder/sa/sa.go

Line 166 in 66a4c11

Created: time.Unix(0, req.Created),

And of course, just using an integer for this leads to fun times if you mess up, because the go zero value for time.Time{} is not the same thing as 0 nanoseconds since the unix epoch.

Thankfully, gRPC offers an alternative: timestamppb. We use it in a couple places:

boulder/sa/proto/sa.proto

Lines 354 to 359 in 66a4c11

	message LeaseCRLShardRequest {
	int64 issuerNameID = 1;
	int64 minShardIdx = 2;
	int64 maxShardIdx = 3;
	google.protobuf.Timestamp until = 4;
	}

Client code is much clearer:

boulder/crl/updater/updater.go

Line 371 in 66a4c11

Until: timestamppb.New(deadline.Add(-time.Second)),

as is accessing the value as a server:

boulder/sa/sa.go

Line 1004 in 66a4c11

req.Until.AsTime(),

So it would be nice to change all of our usages of int64 nanoseconds into timestamppb instead. I think the process will look like this:

1. Rename all of our current int64 fields (e.g. notBefore) to their name plus "NS" for nanoseconds (e.g. notBeforeNS). This change should be safe and deployable because gRPC field names are not sent across the wire, they're process local, so no client or server cares what other clients or servers name the message fields.
2. Add new timestamppb fields to all of our messages, using the old (good) names, and populate them at the same time as we populate the existing nanosecond fields. This change should be safe because adding new fields to gRPC messages is always safe.
3. Switch to reading values from the new fields, completely ignoring the old fields. This change will be safe once the second change has fully deployed.
4. Stop populating and fully remove the old fields. This change will be safe once the third change has fully deployed.