Background
----------
* Below is pasted from https://github.com/stretchr/testify/pull/1379#issuecomment-1548086482
  where I had asked a question on a recent failure we saw in the YDBGo pipelines (and in
  the YDBTest/go/unit_test subtest failures in in-house systems which had go 1.13 and 1.15).

  @HaraldNordgren : Hi. We have a Go application that uses the `stretchry/testify` package. It was
  working fine on various systems with different go versions. But for the past 4 days, our nightly
  pipelines have been failing when run with go 1.13.8.

  ```sh
  $ go version
  go version go1.13.8 linux/amd64
  ```

  The failure symptom is the following (pasted from https://gitlab.com/YottaDB/Lang/YDBGo/-/jobs/4268493955)

  ```sh
  $ go test -short $(go list ./... | grep -v /vendor/)
  # github.com/stretchr/testify/assert
  /go/src/github.com/stretchr/testify/assert/assertions.go:94:23: field.IsExported undefined (type reflect.StructField has no field or method IsExported)
  ```

  The same application also fails on a system with `go version go1.15.15 linux/amd64` but passes on a
  system with `go version go1.18.1 linux/amd64`.

  4c93d8f changed `assertions.go` to add the `field.isExported` call. But looks like that call is only
  supported by recent versions of go.

  Is this seeming regression expected? Thanks.

* And below was the response (pasted from https://github.com/stretchr/testify/pull/1379#issuecomment-1548123630)

  In general I would definitely advise against using the 'master' build of any library. You are better
  off pinning the version to testify@v1.8.2 and you would avoid this issue.

  This repo has been updated to only support Go versions >=1.18.

  Be aware the the Go versions you are using are not officially supported anymore:
  https://endoflife.date/go. It would also be a good idea to upgrade your Go versions.

Fix
---
* I tried pinning the version like was suggested. I tried updating go.mod as follows.

  ```diff
  $ git diff go.mod
  @@ -4,2 +4,3 @@ go 1.13

  -require github.com/stretchr/testify v1.4.0
  +require github.com/stretchr/testify v1.8.2
  +replace github.com/stretchr/testify => github.com/stretchr/testify v1.8.2
  ```

  But the YDBGo pipeline still failed as before when it used go 1.13 or go 1.15.

* I then tried the following change.

  ```diff
  $ git diff go.mod
  @@ -4,2 +4,3 @@ go 1.13

  -require github.com/stretchr/testify v1.8.2
  +require github.com/stretchr/testify v1.4.0
  +replace github.com/stretchr/testify => github.com/stretchr/testify v1.8.2
  ```

  This one failed the same way as well.

* Finally decided to bump the go version required by the pipeline to 1.18 as suggested above.
  Searched for all references of `1.13` in the YDBGo repository in the `develop` branch and
  changed all of them to be `1.18`. In some cases, used `1.18.10` as that was the latest
  golang version in the 1.18 series.

  And regenerated `go.mod` using the following steps. This auto-generated go.mod file is
  included in this commit.

  ```sh
  $ cd YDBGo
  $ echo "module lang.yottadb.com/go/yottadb" > go.mod
  $ go get -t
  go: added github.com/davecgh/go-spew v1.1.1
  go: added github.com/pmezard/go-difflib v1.0.0
  go: added github.com/stretchr/testify v1.8.2
  go: added gopkg.in/yaml.v3 v3.0.1
  ```

* And in the in-house systems that have go 1.13 (Ubuntu 20.04) and go 1.15 (Debian 11), decided
  to install the latest Go version using snap instead of using the old go version from the package
  manager. The install worked fine on x86_64, AARCH64 and ARM32 architectures. With those changes,
  the `go/unit_tests` subtest passes fine on all those architectures when it previously reliably failed.