Add newmode v2

[sharinetmc]

Creates a separate class for NewMode's v2 API since the existing v1 (and the python wrapper the existing NewMode sync is based on will be sunset nest February)

@shaunagm, definitely hoping to discuss Parsons deprecation process with you! Also, wondering if you think v2 should just go in its own folder?
Discussed with @willyraedy some options to go about this. This PR currently follows the 2nd option

1. so one way to do this is with versions so we publish a new version and people have to upgrade to the version of the package to get the new and only the new NewMode connector
2. the other way to do it is have latest have both and then do a deprecation process where like:
   NewMode and NewModeV2 are both available and people can update their code
   All users swap to NewModeV2
   Then you switch NewMode to be V2 as well so both NewMode and NewModeV2 are the v2 version
   All users swap back to NewMode
   Delete NewModeV2

[sharinetmc]

definitely need more robust language here, but am hoping to discuss with Shauna along with the Parsons deprecation/versioning process

[shaunagm]

This sounds pretty good, actually, but once we figure out the approach we might want to provide guidance here.

[shaunagm]

Will the NewMode v1 API stop working in February?

[shaunagm]

Rather than creating a new connector with a different name that would have to be edited in lots of different scripts, can we set some kind of variable, either on the connector or at the global config level, that directs which connector to use under the hood?

I'm imagining something like:

class OldNewMode:
   ...

class NewNewMode:
  ...

if os.environ("UPDATE_NEWMODE_VERSION", "False"):
  class NewMode = NewNewMode
else:
  class NewMode = OldNewMode

So then people wouldn't need to change their scripts at all, just use an environmental variable, and then come Feb we just get rid of the OldNewMode entirely. Unless the old version will still be workable for a while...

I'm not 100% sure the above approach will work but it seems like it should?

[shaunagm]

Not sure if you wanted me to review the whole thing but I took a quick look, obviously the main thing is the deprecation process - happy to talk about this on a call if you'd prefer

[shaunagm]

This sounds pretty good, actually, but once we figure out the approach we might want to provide guidance here.

[shaunagm]

See my comment in the main thread for thoughts on overall design of the deprecation process

[shaunagm]

This method needs a docstring, I'll wait for you to add it before asking questions about the method as I imagine some of my questions will be answered by the docstring

[shaunagm]

If this is easy/straightforward to do it would be great to include a link here to newmode's docs to show what params are allowed and how to format them (same for all methods that accept params)

[shaunagm]

It's a little surprising to see headers defined in a get method