[Enhancement] Strict Staged Builders Support Primitive Optimized Collections

[bmarcaur]

Before this PR

When using useStrictStagedBuilders and nonNullCollections the generated builders did not allow for the optimal (non-boxing) path (#2389), nor did it optimally handle Jackson deserialization (#2431).

After this PR

Strict staged builders now expose additional, optimized setters and also leverage these setters for Jackson deserialization.

==COMMIT_MSG==
==COMMIT_MSG==

Possible downsides?

IMO this class is becoming unwieldy. It has two similar, but somewhat divergent code paths between strict and non-strict builders. You cannot simply hoist the strictness to the top level because it has entry points like addStagedBuilder which you can call even when useStrictStagedBuilders is set to true? Kinda feels like we should have different builder implementations for each of the paths through and we then factor out the bit of shared behavior. IDK it felt bad adding all these boolean strict all over the place.

In addition, I added some complexity to support adding the collection reset. If we are comfortable allowing people to cast into the base builder and break shit.. Then I can remove some of these unwanted boolean stricts.

[bmarcaur]

Hoisted this up as having it nested in the auxiliary setters was a hold over from a time before isPrimitiveOptimized properly guarded for collection types only. Hence it needing to be nested inside a type.accept(TypeVisitor.IS_LIST). However, this is not strictly a refactor for refactor's sake. I did need to add the primitive setter in more cases than what this method is used for.

[carterkozak]

I think this will need a rebase once #2463 merges given we've replaced some of the integrationInput test infrastructure.

@mpritham Could you give this a final review + approval once the test refactoring PR has merged and this has rebased?

[bmarcaur]

I think this will need a rebase once #2463 merges given we've replaced some of the integrationInput test infrastructure.

@mpritham Could you give this a final review + approval once the test refactoring PR has merged and this has rebased?

Yup, chatted with Pritham about this. I'm not in a rush so would rather not disrupt Kunal.

[kunalrkak]

fysa #2463 has merged in, this should be good to rebase! running the test here (with the recreate flag set) will regenerate PrimitiveStrictExample with your changes

[bmarcaur]

fysa #2463 has merged in, this should be good to rebase! running the test here (with the recreate flag set) will regenerate PrimitiveStrictExample with your changes

@kunalrkak @mpritham It rebased eerily cleanly. I still ran gw :conjure-java-core:test -Drecreate=true but it produced no changes so I think this is clean and GTG.

edit: I think I should still address #2464 (comment) before this merges. Its a good suggestion. It will only be a one line change in the generation code. So a review on this need not wait, but you can if you want.