Use PATCH semantics by default to set custom metadata

[pickypg]

This changes the default behavior from POST to PATCH so that the custom metadata passed into VM#setMetadata augments what is already set.

Fixes #168

• Tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

[pickypg]

As was suggested in #168, switching to PATCH semantics may be more appropriate. However, it's unclear to me if this is what was intended by the comment or perhaps this plus some other work.

Specifically, by defaulting to PATCH semantics, it would make it impossible to use VM#setMetadata to delete custom metadata (which is fine for my use case, but I suspect it wouldn't be fine for everyone else's use case).

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[stephenplusplus]

Thank you for this! Unfortunately, the upstream API only accepts POST. When I said PATCH semantics, I just meant what you were proposing was spot on (doing the merging within our library for the user). Sorry for the confusion!

Specifically, by defaulting to PATCH semantics, it would make it impossible to use VM#setMetadata to delete custom metadata (which is fine for my use case, but I suspect it wouldn't be fine for everyone else's use case).

Great point. I added some flare to the code to support removing and updating values.

Let me know what you think!

[pickypg]

Unfortunately, the upstream API only accepts POST.

That's what I was afraid of. I figured it was easier to do the PR to get this going. This is exactly what I had in mind. Thanks!

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

[fhinkel]

@pickypg Thanks for the PR! Could you have a look at the failing lint job?

[pickypg]

@fhinkel sure, but I think it’s best to wait for @stephenplusplus (or you) to comment on the feedback to his modifications.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

[JustinBeckwith]

@stephenplusplus this one is ready for you to review :)

[stephenplusplus]

LGTM! @pickypg thank you for this! 🥇

[pickypg]

Thanks for the handling everyone. I'm excited to see this get into the library so that I can remove the code in my GCF that was doing this manually!