Enable creation of unknown record types

[dholms]

Enables the creation/update of records of unknown lexicon.

By default, a write is still "validated" which requires the existence of the lexicon. However, if the request to the pds is set to validated: false, then the write will be let through. This is higher friction than we want it to be long term, however we don't have any form of dynamic schema resolution yet and I think the extra bit of friction is worth it such that the lack of guardrails is better surfaced to developers.

We generically walk the record to find and associate any blobrefs, even for records that we do not know the schema for.

Some other generic behavior is enforced as well:

• rkey syntax
• record $type matching collection name
• createdAt adheres to the proper date format
• ensuring that blob-refs are not in the legacy format
• generally being able to encode/decode from JSON <> Lex <> CBOR

[devinivy]

Just a gut check that 10 layers is enough for e.g. the images within a record-with-media (counting in my head I suppose it's probably fine, close to 5?). It just feels a little conservative, I'd be down to increase this a bit either way.

[dholms]

Yup fair point, I can bump it up 👍

[devinivy]

💎

[bnewbold]

FYI, I have this parallel PR with some additional data check test cases:
https://github.com/bluesky-social/atproto/pull/2182/files

It checks for things like $link and $bytes objects having the correct data types and no extra fields. Your round-trip tests may already catch these.

Should we consider preventing updates to app.bsky.feed.post, specifically, for now? I think there is already a loophole with delete/create, so maybe that ship has sailed. We just don't have super robust handling of this yet and it could break user expectations until there is more robust client support.