chore: update deps to ones that use maintained form3tech-oss/jwt-go

[jdstrand]

The dgrijalva/jwt-go project is no longer maintained and has a security
vulnerability. Update our dependencies that pull in jwt-go to new
versions that used the security-patched form3tech-oss/jwt-go.

The following was performed:

1. update go.mod to use go-autorest/autorest/adal v0.9.5 (the first
   release to use form3tech-oss/jwt-go)
2. update go.mod to use go-autorest/autorest/azure/auth v0.5.3 (the
   first release to use adal v0.9.5)
3. update go.mod to use snowflakedb/gosnowflake v1.3.13 (the latest
   1.3.x release, which uses form3tech-oss/jwt-go)
4. go mod tidy
5. make test

References:

• Migrating Maintenance dgrijalva/jwt-go#462

IMPORTANT: while gosnowflake remains on v1.3.x, adal moves from 0.8.x to 0.9.x and azure/auth moves from 0.4.x to 0.5.x. While I ran make test and it passed, I did not do any further verification for correctness. Also note, I chose the highest v.1.3.x version for gosnowflake since that seemed safest, but the lowest versions of adal and azure/auth that has the dep fix. I did not verify these for open issues, etc since I felt someone more knowledgeable in flux's use of these dependencies would have more insight on the risk. IMHO, it would be fine to close the PR and instead open another that chooses whatever version of these deps makes sense for flux.

Done checklist

• docs/SPEC.md updated
• Test cases written

[jdstrand]

Adding @rockstar as a reviewer since 745073a pulled in the adal and azure/auth deps while aff8331 pulled in the gosnowflake dep.

[rockstar]

While I ran make test and it passed, I did not do any further verification for correctness.

I don't think anyone on the team has any expertise on the places where these dependencies are used. For instance, the Azure/go-autorest is part of the mssql_azure sql provider, which has no tests (at least for that specific functionality).

I am of the opinion that we should make this change if only for the vulnerabilities attached, and if things break, we take that time to write some tests to verify it. Otherwise we'll continue to add to our maintenance burden without any sort of assurances that we can scale. @nathanielc, does that sound right to you?