SPICE-0021 Implement Pkl binary renderer and parser

[HT154]

This PR is composed of two commits: the first adds the new functionality and the second regenerates all changed snippet outputs. Please review just the first commit.

Implements SPICE-0021

Resolves #994

[HT154]

This PR extracts String-specific functionality to a new AbstractStringRenderer subclass so that binary renderers can still benefit from the converter logic here in AbstractRenderer. This is a breaking change for any out-of-tree inheritors from AbstractRenderer but the fix is as simple as s/AbstractRenderer/AbstractStringRenderer/g.

[sin-ack]

Tested this out, and hit an edge case where if the moduleUri for a Typed binary-encoded value is the empty string, the following exception is thrown:

java.lang.NullPointerException

–– Pkl Error ––
None (cause has no message)

42 | external function parse(source: Resource|Bytes, context: Module): Any
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at pkl.encoding#PklBinaryEncodingParser.parse (https://github.com/apple/pkl/blob/40bcfb18/stdlib/encoding.pkl#L42)

-- (snip) --

Pkl 0.30.0-dev+40bcfb18 (Linux 6.16.3-cachyos, native)

java.lang.NullPointerException
        at org.pkl.core.SecurityManagers.getDefaultTrustLevel(SecurityManagers.java:80)
        at org.pkl.core.SecurityManagers$Standard.checkImportModule(SecurityManagers.java:165)
        at org.pkl.core.stdlib.encoding.PklBinaryEncodingParserNodes$parse$Importer.importModule(PklBinaryEncodingParserNodes.java:126)
        at org.pkl.core.stdlib.encoding.PklBinaryEncodingParserNodes$parse$Importer.importClass(PklBinaryEncodingParserNodes.java:80)
        at org.pkl.core.PklBinaryDecoder.decodeObject(PklBinaryDecoder.java:230)
        at org.pkl.core.PklBinaryDecoder.decodeNonPrimitive(PklBinaryDecoder.java:162)
        at org.pkl.core.PklBinaryDecoder.doDecode(PklBinaryDecoder.java:141)
        at org.pkl.core.PklBinaryDecoder.decode(PklBinaryDecoder.java:109)
        at org.pkl.core.stdlib.encoding.PklBinaryEncodingParserNodes$parse.doParse(PklBinaryEncodingParserNodes.java:62)
        ...

[HT154]

@sin-ack How did you produce the encoded data with the empty module URI string? Was that something you edited by hand?

[sin-ack]

@HT154 It's from outside Pkl itself. We have a custom Pkl binary encoder/Pkl types representation in the host language that previously encoded Dynamics with an empty module URI string (although I'm pretty sure pkl server also returns Dynamics that way, but don't quote me on that). We now use "pkl:base" which works around this.

[HT154]

Gotcha! Both pkl-server's prior implementation and this new one do indeed encode Dynamic's type info with module URI pkl:base and name Dynamic. I'm adding some error handling in place of the unhelpful NPE, but encoding the module URI as an empty string will remain invalid. I'm also improving the binary encoding spec to explicitly document the specifics of type naming for Typed, Dynamic, Class, and TypeAlias values.

[bioball]

Did a first pass!

[bioball]

This is getting pretty close! Made another pass.

[bioball]

Some minor comments. LGTM to merge after they're addressed!

[HT154]

Merging this now, any additional feedback or issues will be addressed in a follow-up PR

[bioball]

@sin-ack FYI: we've moved the in-language parser out of this PR because it executes imports. This goes against the principle that module imports should be statically analyzable (which you can get with pkl analyze imports).

We're considering introducing a new language operator instead to load binary data; something like:

data = load("path/to/bytes.msgpack")

Where load becomes a keyword much like read() and import(). But, we need some time to think through this feature and we're punting it out of the SPICE.

[sin-ack]

That's kind of unfortunate, because having it helped with a use-case we had where we were able to preserve type information for user configuration passed with Pkl binary encoding into the module. Without this, I guess an alternative could be to have a client resource reader expose the data at a relative path and use the relative load() as a pseudo-"dynamic" import. Thanks for letting me know.