Editing a draft post with wp.editPost causes its published date to be set

This bug exhibits the exact same behavior as #16985 did for the MetaWeblog-based API before wp.editPost came along. When wp.editPost was implemented, evidently a regression occurred causing the buggy behavior to rear its head again.

The practical effect of this bug is that a draft post submitted by an API client, and then edited by an API client, will have its publish date "locked in time" to the original submission time. So for example if you start a draft post on May 1, and edit it for two weeks before publishing on May 15, the published post will have a publish date of May 1.

To reproduce using the WordPress XMLRPC API:

1. Create a new draft status post using wp.newPost, omitting dates from the submitted post. This results in a post that has a post_date_gmt that is zeroed out, reflecting the fact it should receive the current time when the post is changed from Draft to Publish.

1. Edit that draft post using wp.editPost, again omitting any dates.

Expected result: the draft post should still have zeroed out publish date (post_date_gmt).

Actual result: the post now has a post_date_gmt value matching the original post_date value that was created when the draft was submitted.

The bug appears to be rooted in the wp.editPost implementation in class-wp-xmlrpc-server.php. Because this method uses the existing post struct from the database as a baseline of all submitted content, the post_date value ends up being set on the struct that is passed to _insert_post. But _insert_post makes assumptions about client intent based on the presence of or absence of values on that struct. So in this case the post_date value on the struct is interpreted as being a client-asserted publish date for the post.

I'm attaching a patch with a possible fix, which is to make a point of unsetting the post_date value on the struct whenever the post_date value is missing from the content_struct provided by the API client.