Update @actions/cache dependency and documentation (#549)

* deps: Update actions/cache dep, rebuild solution, update docs

* docs: fix typo

* deps: update jest dependencies and licenses

* deps: fix vulnerable dependencies, rebuild solution

* licenses: update

README.md

@@ -161,6 +161,22 @@ steps:
   run: sbt package
 ```
 
+#### Cache segment restore timeout
+Usually, cache gets downloaded in multiple segments of fixed sizes. Sometimes, a segment download gets stuck, which causes the workflow job to be stuck. The cache segment download timeout [was introduced](https://github.com/actions/toolkit/tree/main/packages/cache#cache-segment-restore-timeout) to solve this issue as it allows the segment download to get aborted and hence allows the job to proceed with a cache miss. The default value of the cache segment download timeout is set to 10 minutes and can be customized by specifying an environment variable named `SEGMENT_DOWNLOAD_TIMEOUT_MINS` with a timeout value in minutes.
+
+```yaml
+env:
+  SEGMENT_DOWNLOAD_TIMEOUT_MINS: '5'
+steps:
+- uses: actions/checkout@v3
+- uses: actions/setup-java@v3
+  with:
+    distribution: 'temurin'
+    java-version: '17'
+    cache: 'gradle'
+- run: ./gradlew build --no-daemon
+```
+
 ### Check latest
 
 In the basic examples above, the `check-latest` flag defaults to `false`. When set to `false`, the action tries to first resolve a version of Java from the local tool cache on the runner. If unable to find a specific version in the cache, the action will download a version of Java. Use the default or set `check-latest` to `false` if you prefer a faster more consistent setup experience that prioritizes trying to use the cached versions at the expense of newer versions sometimes being available for download.