Update flows client classes to use MISSING defaults

[MaxTueckeGlobus]

sc-15807

Changes

• Converted all defaults of None to globus_sdk.MISSING for all payload types in the flows client.
• Updated the base client’s request functions to allow the MissingType for query_params.
• Updated flows unit tests to test with MISSING defaults instead of None.

Flows OpenAPI spec for reference.

Thought process

When determining if a property's new type should keep or loose its none type, I tried generally to follow this rule:

If the property is both nullable AND a user provided explicit None value has a different behavior than not including the property in the payload, it should transform like so:
field: field_type | None = None -> field: field_type | None | MissingType = MISSING

Otherwise, it should loose its none type and transform like so:
field: field_type | None = None -> field: field_type | MissingType = MISSING

I'm not completely convinced that this is the correct way of thinking about this, so I would very much appreciate any feedback on this. Specifically, any potential cases where this logic breaks down would be useful to try and get a more concrete ruleset to apply to the other client classes.

---

📚 Documentation preview 📚: https://globus-sdk-python--1205.org.readthedocs.build/en/1205/

[sirosen]

I'm not completely convinced that this is the correct way of thinking about this, so I would very much appreciate any feedback on this. Specifically, any potential cases where this logic breaks down would be useful to try and get a more concrete ruleset to apply to the other client classes.

I believe your core rule here is correct.

MISSING allows us to express "nullability" in addition to "omit-ability".

Because the following two JSON payloads are different:

{"foo": null}
{}

Relatedly, the following two python function calls are different:

do_it(foo=None)
do_it()

If we want to support a payload with {"foo": null}, then we want to allow for None. Otherwise, we only want to allow for MISSING.

How we determine which one we want to support hinges on how the underlying API behaves.
For some APIs, PUT /some-route {"foo": null} means "un-set the foo setting", so expressing null, vs missing, becomes important.

Also, we can add None in later if we missed anything, so it's not a strict requirement that we do this perfectly -- we just need to do our best.

---

I'm going to start looking over the PR itself in just a few, but it sounds to me like you're on the right track already in your thinking!

[sirosen]

I have some specific changes I'd like to see. I've commented only on a couple of cases, but please scan the other client methods for FlowsClient in order to find the other ones which "match".

One comment is an open question; I'd like to talk about this with the full team on Monday, if possible, in order to figure out what our collective judgement is about what to do. Your code as-written might be our choice, but I'm trying to avoid assuming that it is or is not what we want.

[sirosen]

Tiny final item. I'm re-scanning now to be sure but I think this is good to go!