feat: move job attachments time stamp to after download. Add a retry to ensure timestamp is updated

What was the problem/requirement? (What/Why)

With the introduction of boto3 CRT, we observed job attachment failures when the code is updating the downloaded file time stamp. A "File not found" exception is thrown when the file system is not fully consistent with the file location.

What was the solution? (How)

Shuffled the business logic and moved the time stamp code to after downloads are complete.
Added a retry mechanism to ensure the code is more resilient to any timing differences.

What is the impact of this change?

This change will pave the way to re-enabling CRT.

Updates

Updated LICENSE file to the latest. Seems it is quite out of date. It now includes the retry library.

How was this change tested?

hatch build
hatch run fmt
hatch run lint

hatch run test
....
....
Required test coverage of 80.0% reached. Total coverage: 84.33%
================================================================================================ slowest 5 durations =================================================================================================
2.05s call     test/unit/deadline_job_attachments/test_upload.py::TestUpload::test_asset_management_no_outputs_large_number_of_inputs_already_uploaded[2023-03-03-100]
1.87s call     test/unit/deadline_job_attachments/test_upload.py::TestUpload::test_asset_management_many_inputs[2023-03-03-100]
1.67s call     test/unit/deadline_job_attachments/test_progress_tracker.py::TestProgressTracker::test_increment_race_condition
1.52s call     test/unit/deadline_job_attachments/test_upload.py::TestUpload::test_asset_management_no_outputs_large_number_of_inputs_already_uploaded[2023-03-03-200]
1.49s call     test/unit/deadline_job_attachments/test_upload.py::TestUpload::test_asset_management_many_inputs[2023-03-03-200]
============================================================================== 1326 passed, 46 skipped, 1 xfailed, 2 warnings in 18.64s ==============================================================================

Running Integration tests, All integration tests passes.

hatch run integ:test
...
================================================================================================ slowest 5 durations =================================================================================================
10.14s setup    test/integ/deadline_job_attachments/test_job_attachments.py::test_upload_input_files_all_assets_in_cas[2023-03-03]
8.74s call     test/integ/deadline_job_attachments/test_job_attachments.py::test_sync_outputs_no_job_attachment_settings_in_job[2023-03-03]
7.18s setup    test/integ/deadline_job_attachments/test_job_attachments.py::test_sync_inputs_with_step_dependencies[2023-03-03]
5.43s teardown test/integ/deadline_job_attachments/test_job_attachments.py::test_download_outputs_windows_max_file_path_length_exception[2023-03-03]
4.48s call     test/integ/deadline_job_attachments/test_job_attachments.py::test_sync_inputs_with_step_dependencies[2023-03-03]
====================================================================================== 14 passed, 1 skipped in 66.15s (0:01:06) ======================================================================================

Was this change documented?

Not applicable, no APIs or customer behaviors are changed.

Is this a breaking change?

No - this change is only moving the code logic around.

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

aws-deadline / deadline-cloud

feat: move job attachments time stamp to after download. Add a retry to ensure timestamp is updated #418