Set maxAttempts to 10 to workaround slower container startup

[danmactough]

Since switching to aws-sdk-v3, we're seeing a lot of random errors like:

  console.error
    Error: AWS SDK error wrapper for TimeoutError: socket hang up
        at asSdkError (/Users/daniel.mactough/code/partner-service/node_modules/@smithy/middleware-retry/dist-cjs/index.js:103:10)
        at /Users/daniel.mactough/code/partner-service/node_modules/@smithy/middleware-retry/dist-cjs/index.js:327:21
        at processTicksAndRejections (node:internal/process/task_queues:95:5)
        at /Users/daniel.mactough/code/partner-service/node_modules/@aws-sdk/client-dynamodb/node_modules/@aws-sdk/middleware-logger/dist-cjs/index.js:34:22
        at deleteTable (/Users/daniel.mactough/code/partner-service/node_modules/jest-dynamodb-local-docker/lib/table-helpers.js:69:3)
        at Object.<anonymous> (/Users/daniel.mactough/code/partner-service/test/lib/task-store.test.js:69:5) {
      '$metadata': { attempts: 3, totalRetryDelay: 25 }
    }

 FAIL  test/lib/task-store.test.js
  ● Task Store › createTask › creates a task

    AWS SDK error wrapper for TimeoutError: socket hang up

I thought this was a manifestation of jestjs/jest#2549 impacting the handling of retry errors due to the pervasive use of instanceof checks in aws-sdk-v3 similar to aws/aws-sdk-js-v3#3851. I also thought this might be related to jest fake timers interfering with aws-sdk-v3 connection timers. Eventually, I tried just increasing the number of retries and that seems to have resolved the errors. It doesn't seem worthwhile to try to find the "sweet spot" on this configuration parameter -- I imagine something less than 10 attempts would be sufficient -- but I'd rather this Just Work™ (which the value of 10 seems to do).