BW-1317 Upgrade googleCloudNioV to latest

[aednichols]

Last time we tried to upgrade this we ran into a bug, but it has now been fixed and we have a unit test for the library that verifies the fix.

Besides generally keeping important libraries up to date, there is a chance that recent fixes to requester pays (Google PR, GATK PR) implemented by our own very Methods team may solve an issue users are seeing in Terra:

User project specified in the request is invalid.

Terra User Liaison Slack link.
DSP Methods Slack link.

[aednichols]

It always makes me a little uneasy deleting "danger!" comments but we do have a test and the proof of the pudding will be in the eating

[breilly2]

Documenting my review process here.

For dependency updates, I like to review the changelog. In this case, we're going from 0.61.0-alpha to 0.124.8 which is a large jump, but that doesn't tell the whole story.

• This looks like a lot of releases to check. For sure, checking every release manually is not practical; we'll have to rely on their release notes.
• Until 0.120.0, this library used to be included in a monorepo-ish repo of Java libraries which appears to have had a regular 2-week release cycle. Not every release had changes to the google-storage-nio library. In fact, browsing the release notes, I found only a handful that mentioned changes to storage NIO. These all looked very innocent to me.
• After 0.120.0, the library code moved to its own repo. Releases there have been less frequent and more irregularly scheduled, but still largely consist of dependency updates. (It's possible that those dependency updates introduce unexpected behaviors in java-storage-nio, but there's only so much we can audit).
• Cromwell was briefly running with 0.123.8 until the bug mentioned here was discovered. Not knowing when that bug was introduced, we rolled all the way back. Now, we are pretty confident that it was introduced in 0.122.0 and fixed in 0.123.13.
• Again looking at releases that are not just dependency updates, nearly all of the changes look very innocent to me. In fact, updating to at least 0.123.23 will give us the benefit of a fix to a requester-pays problem that we encountered ourselves.
• There's only one other post-0.120.0 change (in 0.123.18) that raises my eyebrows a little. It's probably fine, but there is new usage of StorageOptionsUtil.getDefaultInstance() for which I don't know the lifecycle or how else it's used. This is the type of thing that I'd watch out for in terms of thread safety, which is the root of the problem that caused us to rollback before.

In summary, it's probably safe to go all the way to the most recent version. In fact, my gut feeling is that the risk is low enough to be outweighed by the benefit of being up-to-date.

[cjllanwarne]

Love @breilly2 's analysis. 👍 from me.

[aednichols]

Likewise, thank you @breilly2 for the analysis!