fix: handle missing checkpoint token from service

[ayushiahjolia]

Issue #, if available:
#43
#565

Description of changes:
Standardizes how the SDK handles a missing/empty CheckpointToken from the Durable Functions API, and makes the checkpoint loop treat an absent response token as a first-class terminal signal. Previously the token was defaulted to an empty string and could be forwarded to checkpoint_durable_execution, where boto3 rejects a zero-length value with a ParamValidationError — crashing the background checkpoint thread.

Background -
The service omits CheckpointToken from a checkpoint response in exactly one case: the terminal checkpoint that ends the execution (an EXECUTION op with action SUCCEED/FAIL). Every non-terminal checkpoint — including empty/no-op ones — returns a fresh token, and the invocation event always carries a seed token. So an absent token legitimately means "the execution is over"; anywhere else it is an invalid response, and an empty token must never be sent back.

Situation	Behavior
Non-terminal checkpoint, token present	rotate to it (unchanged)
Execution end, small result	SDK checkpoints no terminal op; backend finalizes from the invocation response — no null token seen (unchanged)
Execution end, large result / failure (SDK checkpoints the terminal op)	recognized as completion: loop stops, queued orphan work settled, no further request issued
Non-terminal checkpoint returns no token	invalid response → retryable CheckpointError → re-drive
Empty/None token about to be sent (e.g. malformed seed)	retryable CheckpointError / GetExecutionStateError; no boto crash
parallel/map early completion (min_successful, failure tolerance) with branches still running	racing branch checkpoints settled as orphaned; later ones rejected fast; nothing sent post-completion
Nested concurrency + timed waits, orphaned after completion	resubmitter stops cleanly, no timer-thread crash

Every token anomaly resolves to a retryable error that re-drives with a fresh token; the one legitimate absent token (execution completion) is handled silently, and an empty token is never transmitted to the service.

Testing - Added unit tests

NOTE: Intentionally diverges from the JS/Java SDKs; they should be updated to match (guard empty-token sends, fail on non-terminal null).

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[zhongkechen]

When we call _checkpoint_queue.put here, the condition self._execution_completed.is_set() might have been changed by another thread since previously checked.