Revise repo write validation for unknown Lexicons

[devinivy]

To date when using com.atproto.repo.{createRecord,putRecord,applyWrites} to write to a repository, by the default the PDS will reject any writes into a collection with a Lexicon unknown to the PDS. This behavior is controlled by the validate input. We would like to change this behavior in order to be forward looking into a world where a PDS may have a dynamic set of Lexicons that are either resolved on the fly or otherwise loaded at runtime.

Record validation by the PDS is a driver of coherent/compatible data across the network, but network participants can't rely on all data in the network adhering to a given Lexicon: ultimately each party (e.g. an appview, feed generator, or client app) needs to validate repo records themselves. So while validation within the PDS is very useful to nudge applications towards writing proper data, it provides no strong guarantee. Furthermore, a PDS's access to a given Lexicon should not be a bottleneck to users' usage of apps that rely on it. Otherwise you could easily imagine downtime of a service that serves a given Lexicon cascading into write degradation for all apps making use of it. Since validation at the PDS provides no strong guarantee, it's not worthwhile to have such a bottleneck.

The proposal here is to a. loosen the requirement that by default the PDS must have a given Lexicon to permit writes, b. report back to the caller whether the PDS was able to perform validation. More specifically we'll update com.atproto.repo.{createRecord,putRecord,applyWrites} such that:

• the validate input no longer has a default (technically a breaking change for PDS implementations). When validate is not set, the PDS will perform validation for any Lexicons available to it and skip validation for any Lexicons unavailable to it.
• Responses to createRecord and putRecord include a new optional field validationStatus that will be set to 'valid' if the PDS was able to validate the record and 'unknown' otherwise.
• The applyWrites method now has a response containing the a list of write results, preserving the order of the writes input received.

[dholms]

looks great 👌