101: Don't retry POSTs

[lindsay-stevens]

Closes #101

• main problem is retrying POST which can result in duplicate data
• default central timeout is 120s so pyodk default increased (from 30s) to match

What has been done to verify that this works as intended?

Ran the existing client tests to check that normal / low intensity usage is unaffected.

For the methods change, thought about adding more tests but they perhaps weren't very useful except to document the requirement that POSTs shouldn't be retried - like a test that does a POST and verifies that it's not retried? Probably if someone were considering changing the method list in future they would do some research and find this PR and the linked ticket.

For the timeout change, this might be useful to test i.e. to show how pyodk behaves when Central is taking a while to respond. If seems like a good idea I could do that, but I would suggest creating a dedicated performance test host rather than slamming dev/staging. Or add a local testing Central instance (e.g. with compose) so pyodk doesn't have an external dependency.

Why is this the best possible solution? Were any other approaches considered?

As discussed in the ticket and above it should reduce the likelihood of duplicate data if Central is taking a while to complete requests. An alternative up til now (and still) noted in the readme is to customise classes in session.py and provide a custom Session to the Client.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

The worst case total wait time is 8.5min up from 2.5min which might be an issue if users of pyodk assumed a shorter timeout e.g. a job/script gets cancelled if it takes longer than 5 mins but they assumed it would try at least 2 things. Similarly users might have relied on POSTs being retried. But as mentioned above the old behaviour can be maintained by customising the Session.

Do we need any specific form for testing your changes? If so, please attach one.

N/A

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No this level of implementation detail isn't in the docs.

Before submitting this PR, please make sure you have:

• included test cases for core behavior and edge cases in tests
• run python -m unittest and verified all tests pass
• run ruff format pyodk tests and ruff check pyodk tests to lint code
• verified that any code or assets from external sources are properly credited in comments