Fix nullable decoding

[lewisjkl]

Creating as a draft because I think the "solution" I have here may not be the right way to go at this, but wanted to get some thoughts about this in general before continuing. The issue is that if you have, for example, a Smithy structure that looks like:

structure Foo {
  @required
  @nullable
  str: String
}

Smithy4s will decode the JSON payload {} into Foo(Nullable.Null). I would think this is incorrect since the field is required and has no default value (if it had a default value of null, then it'd be working as intended).

I worked on tracking the issue down, and figured out that it is because our Nullable schema is a Bijection to Option. So when the JCodec Schema Visitor goes looking for the default value, it returns Some(Nullable.Null) rather than None for this case. I (at least temporarily) fixed this by modifying the bijection method of the OptionDefaultVisitor, but I'm not sure whether or not this approach is sound.

---

In this PR, I also investigated the case of:

structure Foo {
  @required
  // @nullable // tested both with and without nullable
  str: RefinedType = null
}

// would have refinement trait on it
string RefinedType

The behavior for this was not as expected, for example in the non-nullable case {} would result in Missing required field error. This is incorrect since in this case it should give an empty string (assuming empty string is a valid part of the domain set of possible values for the refinement type).

---

PR Checklist (not all items are relevant to all PRs)

• Added unit-tests (for runtime code)
• Added bootstrapped code + smoke tests (when the rendering logic is modified)
• Added build-plugins integration tests (when reflection loading is required at codegen-time)
• Added alloy compliance tests (when simpleRestJson protocol behaviour is expanded/updated)
• Updated dynamic module to match generated-code behaviour
• Added documentation
• Updated changelog

[lewisjkl]

this.apply(schema) will return Some(None), which when doing .map(bijection.to) becomes Some(Nullable.Null). Basically these concepts are not treated the same since Option.empty is the absence of value while Nullable.Null is the inclusion of an explicit Null.

[lewisjkl]

Note that I was not able to create any test cases that indicated an implementation for refinements would do anything here. Every case I could think of would still bypass calling the refinement case. The DefaultValueSchemaVisitor did need to be updated however.

[lewisjkl]

Looks like this test case was actually asserting the wrong thing. In this case, a null default on a non-nullable field means that the default value is assumed to be 0

[lewisjkl]

Before merging this, I think it will be helpful if I add documentation that shows each different combination of required, nullable, and null default and what happens (probably some tests to show this too).