Update golang.org/x/text to resolve some vulnerabilities

[robertcnix]

• CVE-2022-32149
• CVE-2020-14040

[apparentlymart]

Hi @robertcnix,

This module does not use the "language" subpackage of golang.org/x/text, and so nothing in this package is affected by those security advisories.

There are some other changes in this release of golang.org/x/text that are not security-related but are potentially breaking for callers (the implementation of the GB18030 encoding, the IDNA normalization rules, and currency formatting) which cty doesn't make use of but may be in use by callers of cty, and so I am intentionally holding back upgrading the golang.org/x/text dependency until this module itself requires something in a newer version. This then allows cty callers to decide whether to upgrade or not, rather than being forced to upgrade.

If you have an application which depends on this library and receives golang.org/x/text indirectly then you can perform an upgrade which will affect only your application, by specifying newer versions in your own go.mod.

Thanks!

[robertcnix]

@apparentlymart Why does it matter that this package doesn't uses it. This package is using a version that includes vulnerabilities and it gets included as transitive dependencies in other packages that use this package. What's the harm in a minor version bump? All the tests pass with this new version.

[apparentlymart]

If I make go-cty depend on a newer version of this package then no application which uses go-cty can remain on the old version. If I leave it as-is then callers can decide for themselves which version they wish to use, including upgrading to the new version if the security advisories affect their application.

The changes upstream don't affect go-cty but they could potentially affect other software which uses go-cty, if they also directly use golang.org/x/text.