Type-safe parsing of JSON response

[jclou]

Changes:

• Migrated most PBMORTB response model objects to Swift. The remaining model objects use objc generics which are not compatible with Swift and will need further consideration to migrate. Helper functions in JSONParsing.swift keep the model object code simple and ensure consistent and type-safe conversions to and from JSON.

Additions:

• Added API to let publishers provide their own custom model objects and response JSON handling.

Fixes:
-Made PBMORTBAbstractResponse.ext nullable to handle the case in -[PBMORTBAbstractResponse initWithJsonDictionary:extParser] where it does not get set. This case previously existed in tests, but after migrating PBMORTBBidExt to swift, the nil objc class instance instead became an uninitialized Swift class instance and crashed.

• Added nil check to Swift function call in -[PBMAbstractCreative handleClickthrough:sdkConfiguration:completionHandler:onExit:]

[YuriyVelichkoPI]

Please, remove PBM prefix in new Swift classes.

Since we are switching converting JSON to Swift. can we use advantages of Codable?

[jclou]

Its possible to use codable, but in my experience Codable tends to be too strict for most uses. In our case I think we want to prioritize successful parsing of response objects over enforcing strict conformance to the response spec. If for example for some field the response contains "true" instead of the expected true, we would probably want to fallback to a default value rather of failing to decode the entire object.

You could loosen strictness in these cases, but this is not the default behavior and you would need to write your own custom decoding logic and the end result is usually harder to read and more error prone than alternatives.

[jclou]

@YuriyVelichkoPI Can we hold up on this PR and prioritize merging in the SPM migration PRs? Those PRs include the swift migration part of this PR, and I'd like to avoid having to do a rebase/merge. I can add back in the custom class feature afterwards.

[YuriyVelichkoPI]

Its possible to use codable, but in my experience Codable tends to be too strict for most uses. In our case I think we want to prioritize successful parsing of response objects over enforcing strict conformance to the response spec. If for example for some field the response contains "true" instead of the expected true, we would probably want to fallback to a default value rather of failing to decode the entire object.

You could loosen strictness in these cases, but this is not the default behavior and you would need to write your own custom decoding logic and the end result is usually harder to read and more error prone than alternatives.

Thanks for the clarification. Makes sense. We can try Codable later.