PHPC-1411: Accept 64-bit integers for wTimeoutMS

[alcaeus]

https://jira.mongodb.org/browse/PHPC-1411

[alcaeus]

Updated now that CDRIVER-3396 has been fixed. Contains the single commit from #1060 until that PR is merged.

[alcaeus]

@jmikola: updated the logic again after our discussion yesterday.

I've added a few new symbols:

• The php_phongo_int64_to_zval function converts an int64_t to a zval, either as string or as a MongoDB\BSON\Int64 instance
• The php_phongo_parse_int64 parses a string as 64-bit int; this was mainly done to avoid duplicating that logic even more
• The ADD_ASSOC_INT64_COMPAT macro wraps a php_phongo_int64_to_zval and ADD_ASSOC_ZVAL call to avoid adding more compiler conditionals for PHP 5.

The wTimeout of a WriteConcern object is now always serialised as string and can also be unserialised as such. This makes sure that the timeout is truly portable between 32-bit and 64-bit architectures. bsonSerialize continues to return an Int64 object for the timeout.

[jmikola]

Does it make sense to always call php_phongo_int64_to_zval here? php_phongo_write_concern_get_properties_hash is called from three places:

• get_debug_info handler
• get_properties handler
• bsonSerialize() method

We know that bsonSerialize() needs to conditionally use an Int64 object if the value exceeds the range of a 32-bit integer. If wtimeout is within the range of a 32-bit integer, we can add it as an integer primitive.

The debug and properties handlers need not ensure compatibility between 32-bit and 64-bit architectures (unlike serialize(), so I think they'd do well to also encode as an integer whenever possible and only fall back to a string on a 32-bit architecture when wtimeout exceeds the range of a 32-bit integer.

[alcaeus]

The idea was to always export as a string, since code might be serialised using var_export on a 64-bit architecture and then read on a 32-bit architecture. In this case, we'd export as an int, but then be unable to read it. That was the main reason for always treating it as if we were on a 32-bit platform.

[jmikola]

Ah, I wasn't too concerned about var_export being used across platforms since it actually produces code that the user would probably manually edit (unless they're using eval()). I was thinking of serialize() as the more likely way folks might transport between platforms.

In my experience (from GitHub issues), most people using var_export are doing so as an alternative to var_dump and didn't actually rely on __set_state() to rebuild an object.

I'm happy to have var_export produce a string as needed, though.

[jmikola]

Note: I will follow up with a PR against your branch when I get a chance.

[jmikola]

@alcaeus: Opened alcaeus#2 with proposed changes. This allowed me to revert most of your test changes here, but I also added some new tests.

[alcaeus]

Thanks Jeremy! I've added your changes to this PR, so I think this is good for another review 🎉

[jmikola]

One suggestion for something I overlooked in the PR to your branch.

LGTM!