Update api to v3.5

[luandy64]

Description of change

This PR updates the API version from v3.3 to v3.5 in accordance with Google's deprecation of v3.3.

Manual QA steps

Testing the Multiple Schema Handling

I was able to run the tap and add uniqueReachAverageImpressionFrequency to the report. This resulted in a Catalog with
the following schema in it

"uniqueReachAverageImpressionFrequency": {
  "type": [
    "null",
    "number",
    "string"
  ]
}

I was able to run a sync as well. For uniqueReachAverageImpressionFrequency, I was able to sync values "123.456" and "some_field". The tap was able to convert these to "uniqueReachAverageImpressionFrequency": 123.456 and "uniqueReachAverageImpressionFrequency": "some_field" respectively.

And on the "some_field" values, I saw the warning I added WARNING Failed parse field as double.

Finally, I ran the outputted records through target-stitch to compare the records to the schema INFO avb_report (1636): Batch is valid

Risks

I noticed the following fields had schema changes

dfa:uniqueReachAverageImpressionFrequency started as a double and is now a string
                dfa:uniqueReachClickReach started as a long and is now a string
           dfa:uniqueReachImpressionReach started as a long and is now a string
                dfa:uniqueReachTotalReach started as a long and is now a string
              dfa:conversionId (required) started as a long and is now a string

This has been addressed by including the old schema and the new schema in the catalog. So if a report will continue to pull a value like 123.456, the tap won't try to convert it to a string and cause a column to split in a downstream system. The moment a string value for any of these fields occur though, expect your warehouse to have two columns to hold the data.

Rollback steps

• revert this branch

[KAllan357]

Logger?

[luandy64]

I was just avoiding another import and since I had sys already, I figured I would use it