Stop supporting Xml in queries

I've stripped out the XML handling everywhere except XeroQueryCacheTest and XeroQueryExecuteTest. To fix those, we need an example of a full json response.

XeroNormalizer::deNormalize() was heavily assuming xml. I suspect this might be why we have struggled with using json recently. I've attempted a fix.

The XeroQueryCacheTest unit test was failing for reasons I wasn't clear about, so I replaced it with a much simpler kernel test in XeroQueryExecuteTest. At the same time, I noticed that XeroQueryExecuteTest was getting a xero_user response to a xero_contact query, so fixed that.

I suspect the test fail in XeroDeserializationTest is a genuine fail indicating a bug.

OK, the test fail turned up an unrelated bug I've opened a new issue for #3242097: Allow deserializing readonly properties.

I think this is now ready.

We will probably need a follow-up to address deserialization of json date values, as these are untested and may not be working.

I'm not sure how Drupal will handle:
"UpdatedDateUTC": "\/Date(1615463133377+0000)\/",

To compound the problem, our data types sometimes specify datetime_iso8601 and sometimes string. I seem to remember we've also hit problems with the Drupal datetime_iso8601 expecting an explicit timezone but Xero implying UTC.

We may need to develop our data type e.g. xero_iso8601 that can accomodate our needs, use it consistently on all date properties, and then custom deserialize these properties to digest Xero's numeric json date values. Or maybe we just switch all our typed data to use timestamps.

On reflection, I suggest we fix the dates here. Otherwise HEAD might be rather broken.

Let's fix it by deserializing any date values into DrupalDateTime objects and calling $item->setDateTime($date). This will work with any typed data property that implements DateTimeInterface.

Here's how we parse dates:

if (preg_match('#^(/Date\()([-]?[0-9]+)([0-9]{3})([+-][0-9]{4})?(\)/)$#', $data, $matches)) {
    // Handle Xero API DateTime formats. Examples:
    // "/Date(1436961673000)/" - unix timestamp with milliseconds
    // "/Date(1436961673000+0100)/" - with an additional timezone correction
    // "/Date(-1436961673000-0530)/" - before the epoch, 1924 here
    //
    // RE matches for "/Date(1436961673090+0100)/":
    // [1] = (/Date\()          "/Date("
    // [2] = ([-]?[0-9]+)       "1436961673"    epoch seconds
    // [3] = ([0-9]{3})         "090"           milliseconds
    // [4] = ([+-][0-9]{4})?    "+0100" or ""   optional timezone
    // [5] = (\)/)              ")"

    $result = DrupalDateTime::createFromFormat('U u', $matches[2] . ' ' . $matches[3] . '000')
        ->setTimezone(new \DateTimeZone($matches[4] ?: '+0000'));
}

per https://stackoverflow.com/a/56380900

I've added a sane & straightforward way of handling Xero dates.

(This added even more complexity to the tangle that is XeroNormalizer::denormalize() so I opened #3245232: Refactor XeroNormalizer::denormalize into multiple services.)

However, what I've done may not work because our typed data's date handling is not sane and straightforward. For example, InvoiceDefinition is doing this:

      $info['Date'] = DataDefinition::create('string')->setLabel('Date')->addConstraint('Date');
      $info['DueDate'] = DataDefinition::create('string')->setLabel('Due Date')->addConstraint('Date');
...
      $info['ExpectedPaymentDate'] = DataDefinition::create('datetime_iso8601')->setLabel('Expected Payment Date');
      $info['PlannedPaymentDate'] = DataDefinition::create('datetime_iso8601')->setLabel('Planned Payment Date');
...
      $info['UpdatedDateUTC'] = DataDefinition::create('datetime_iso8601')->setLabel('Updated Date')->setReadOnly(TRUE);

We're not consistent in using date definitions on date properties.

Getting an invoice according to Xero docs returns things like this:

      "Date": "\/Date(1518685950940+0000)\/",
      "DueDate": "\/Date(1518685950940+0000)\/",
      "DateString": "2009-05-27T00:00:00",
      "DueDateString": "2009-06-06T00:00:00",
...
      "UpdatedDateUTC": "\/Date(1518685950940+0000)\/",

Although in some cases in the invoice getting docs I also see

    "UpdatedDateUTC": "2009-08-14T21:04:58.09",

Posting invoices looks like this:

  "Date": "\/Date(1518685950940+0000)\/",
  "DueDate": "\/Date(1518685950940+0000)\/",
  "DateString": "2009-05-27T00:00:00",
  "DueDateString": "2009-06-06T00:00:00",

(DueDateString is a weird poorly documented convenience alternative I think, there is no comparable ExpectedPaymentDateString).

It looks like our current code could be use either string or datetime_iso8601 as the definition for date properties, because Xero's xml would return a string time format that was straightforwardly understood by both string and datetime_iso8601. And we could post xml "DueDateString" with value "2009-06-06T00:00:00" and Xero would be OK.

I need to check whether Xero will magically understand "DueDate": "2009-06-06T00:00:00". If it doesn't, then I see no alternative but to get more consistent about how we define date properties so we know when Xero is going to expect us something formatted in a special way. This could be a BC break.

OK, this is going to be easier than I feared. Xero allows us to post in either date format.

Therefore we don't need to worry about normalization of dates at all, we can continue to use the existing output of our string/datetime_iso8601 properties.

And therefore for denormalization all we have to do at this point is detect examples of Xero's weird json Date format and convert it into an iso8601-like string of the kind the XML api has been giving us.

We can leave our data types untouched for now.

The last commit significantly refactors XeroNormalizer::denormalize().

This has become necessary because the remaining test fail indicates ou denormalization of nested json items is failing. I believe this i because the denormalizer was refusing to denormalize anything that wasn't wrapped in an array keyed by plural name, such as the invoice contact in a json response.

This is ready now I think.