Fix making calls with Timezones as well as a few issues caused by the…

[Garethp]

Fix making calls with Timezones as well as a few issues caused by the new TypeConverter, which could be seen when trying to retrieve timezones from the server. Also support running tests with oauth token instead of just username/password

This should solve #269

This MR does the following:

• Converts string to \DateInterval
• When generating classes, detects when there's an empty type (No properties/methods) and replaces it with it's parent's type. We do this because the current generation was looking for the Transition class when it was being supplied the TransitionType class.
• Makes the TypeConverter "extract" out properties when a class has a single property and that property doesn't go into the type it wants to inject into. Essentially the same as how we "drill down" responses.
• Fixes the object for TimezoneContext in the SoapClient
• Add regression tests for fetching timezones and for fetching individual items.
• Allow tests to be run with oAuth tokens instead of username/password.

On the last note, not all tests will work with oAuth tokens. Noticeably the ExchangeAutodiscoverTest test expects a password, and ExchangeAutodiscover doesn't actually have a method for using an oAuth token, so we'll need to fix that in another PR.

[Garethp]

@kambereBr, I'm just pinging you to see if you can spot any issues with the changes I've made to the TypeConverter in this PR

[kambereBr]

@kambereBr, I'm just pinging you to see if you can spot any issues with the changes I've made to the TypeConverter in this PR

@Garethp it looks great. Thanks!

[kambereBr]

@Garethp just tested this by saving a draft message and got an error. More details coming shortly.

[kambereBr]

@Garethp just tested this by saving a draft message and got an error. More details coming shortly.

@Garethp I'm not sure why, but string values mysteriously become arrays when recursively processed through the unwrapping logic (specifically the count($valueProperties) === 1 condition). The current direct property mapping approach avoids this issue entirely.

[Garethp]

@kambereBr Unfortunately the direct conversion was causing issues where Exchange sends objects wrapped weirdly. I don't have the exact example to hand, but if you try to run the Timezone test with the added code commented out, you'll get a result of null timezones as a response.

Do you have some failing code that I can play around with?

[kambereBr]

@kambereBr Unfortunately the direct conversion was causing issues where Exchange sends objects wrapped weirdly. I don't have the exact example to hand, but if you try to run the Timezone test with the added code commented out, you'll get a result of null timezones as a response.

Do you have some failing code that I can play around with?

@Garethp I ran additional tests with my scripts, and everything works fine, nothing is broken. The issue I reported earlier was tested directly with https://github.com/cypht-org/cypht, but I believe the problem comes from its implementation there, not here. Sorry for the confusion, your code looks great. If I encounter any issues, I won’t hesitate to report them. Thanks!

[Garethp]

That's great news! Thanks for testing it out, I really appreciate it!