Resolution of repo v3 commit prev being both nullable and optional

[bnewbold]

Last year, we made some changes to atproto repositories, resulting in "version 3". We mostly removed the concept of prev pointers (as CID Links) to previous commits, forming a chain of history. But we both wanted to keep the functionality around in case somebody wanted to use it, and wanted to minimize disruption and keep older v2 repository commits basically compatible. So we said the prev field would be both "optional" (the field can be entirely omitted from commit objects) and "nullable" (the field can be included, with a null value; a real non-null value could also be included, of course).

Unfortunately, this caused interoperability problems with our Relay implementation, which is in golang. Some languages and JSON/CBOR libraries can represent optional+nullable fields with no loss, but the idiomatic way to serialize data structures in golang works only one way or the other. This resulted in signature validation errors when the field was ommitted (as opposed to having a null value), as discovered in bluesky-social/indigo#327

This has been lingering protocol tech debt for a while, and we want to get it resolved.

Our current plan is to bend the rules of protocol stability, accept that this field de facto has needed to be non-optional for v3 repos all along, and update the v3 spec to match the reference implementation. In other words, the prev field will be required, but nullable, and we aren't going to increment the repo version. We don't love updating the spec to match implementation, but care more about having them be consistent, and expect this to be a pragmatic, low-impact resolution of the issue.

PRs implementing this change (not yet merged):

• specs: specs: v3 commit prev as nullable but non-optional atproto-website#291
• typescript: repo: commit prev as nullable, but non-optional #2173