Common: fix API Request Enrichment output deserialization

[oguzhanunlu]

io.circe.jackson.mapper deserializes all integers and numbers to JsonBigDecimal and downstream in the codebase, it is converted to DecimalNode by circeToJackson() in iglu-scala-client, and the validator treats DecimalNode as number which results in a bad row with number found, integer expected error message in case output schema of API Request Enrichment contains integer property

We'll introduce a custom mapper whose only difference compared to the original mapper is how integers are deserialized. Unlike the original, it'll deserialize integers to JsonLong.

Note that json schemas might contain integer values that don't fit into Long and this case will also result in a bad row, but we don't expect to see this case in real life.

The actual diff happens in CirceJsonDeserializer.deserialize where

case JsonTokenId.ID_NUMBER_INT | JsonTokenId.ID_NUMBER_FLOAT =>
  (Some(Json.JNumber(JsonBigDecimal(jp.getDecimalValue))), parserContext)

is replaced by

case JsonTokenId.ID_NUMBER_INT => (Some(Json.JNumber(JsonLong(jp.getLongValue))), parserContext)
case JsonTokenId.ID_NUMBER_FLOAT => (Some(Json.JNumber(JsonBigDecimal(jp.getDecimalValue))), parserContext)

[chuwy]

The bug manifests itself as a bad row produced by post-enrichment schema-validation. The offending entity is added by API Request enrichment. If its output schema requires integer type, the validator complains that "42 is a number, but integer expected", because in its internal representation, 42 is a number.

[chuwy]

What about SQL Query enrichment, @oguzhanunlu? It's inputs also seem to be affected, but I don't see any changes regarding to that.