trees: Updates for mtpublisher HTTP client and writing checkpoints to tiles

[beautifulentropy]

• trees/checkpoint: Add signed note assembly for mirror submission and serving
• trees/cosignature: Add SignatureLine and accept signature lines as bytes
• trees/mirror: EntryPackage accepts entries as bytes

[jsha]

As a possible future enhancement: my head starts to spin with the layers of encoded types here: signature line, timestamped signature, and ML-DSA signature.

A signature line is represented for us by note.Signature, but we want more. Perhaps we can further parse a note.Signature into something that expands all the fields we want?

type MLDSACheckpointSignature struct {
  Name string
  Hash uint32
  Timestamp uint64
  MLDSASignature []byte
}

And then for instance RawSignature just becomes a reference to .MLDSASignature, and TimestampedSignature becomes an accessor method that concatenates Timestamp and MLDSASignature.

[beautifulentropy]

As a possible future enhancement: my head starts to spin with the layers of encoded types here: signature line, timestamped signature, and ML-DSA signature.

A signature line is represented for us by note.Signature, but we want more. Perhaps we can further parse a note.Signature into something that expands all the fields we want?

type MLDSACheckpointSignature struct {
  Name string
  Hash uint32
  Timestamp uint64
  MLDSASignature []byte
}

And then for instance RawSignature just becomes a reference to .MLDSASignature, and TimestampedSignature becomes an accessor method that concatenates Timestamp and MLDSASignature.

I understand the attraction to defining this as a type, but I don't believe it's the right fit in this case.

In the publisher, when reconstructing a signature line from the database, the name and hash come from the MTCA Verifier we already have access to on the publisher struct. Later, when sign-subtree returns its signature lines, we sift through them for the one that matches our mirror verifier and return it as a timestamped_signature, which RawSignature then checks is zero timestamped and strips down to the ML-DSA signature. That raw signature is the only thing we store. The name, hash, and timestamp are never needed past that point, so parsing them out gets us nothing.

In the MTCA, when we reconstruct a line from the database (which is going away), the name and hash come from the MTCA and mirror Verifiers, just like the publisher.

I actually tried implementing this in two ways. First, as the struct above. Callers filled in the name and key ID from their respective verifiers only for SignatureLine to copy them straight back out, and nothing ever read them. Second, as just Timestamp and Signature, with SignatureLine still taking the name and key ID as arguments. That version was net smaller, RawSignature and its test went away, but every call site that had to hand one to SignatureLine (3) got a lot busier without making the code any easier to reason about. Also, the final step before passing the Signature field to the database for storage involves checking that Timestamp is actually zero, which feels kind of weird because it would be super easy for a caller to forget to do that. With RawSignature there's nothing to forget, all it does is produce the zero timestamp confirmed raw signature from a timestamped_signature.