Diversifying the reflection API usage, for DeploymentReader test

[advancedwebdeveloper]

Consult the following discussions, for farther details:
https://groups.google.com/g/golang-nuts/c/S2gBW3BV4QU/m/I4gWtrPxBwAJ
#1130

Compared to a summary, known threw a patch https://gist.github.com/advancedwebdeveloper/9ee1d333d0101b06823735cf871055b1 - the code above was not formatted automatically, via https://pkg.go.dev/golang.org/x/tools/cmd/goimports

[mrutkows]

Although I have read the attached discussion thread (which itself lacked context) I am not inclined to begin using a 3rd party alternative unless there is a compelling reason to especially if there are no apparent functional issues with the code as it exists today. In addition, it seems that the actual owner of the "reflect" lib in golang itself is trying to understand some minor optimization and resultant performance issues and fix them in the base golang; if so, then I am inclined to wait for those changes to be picked up in an actual golang release/update.

Also, we should not be using Travis PR builds simply to use as an alternative local test bed; the ASF pays for Travis.com usage and we should not be abusing the privilege. Unit tests for your purposes (i.e., testing a new lib.) are sufficient until you are ready to submit a final PR with the complete solution along with additional unit tests. If indeed, you are fixing a problem, we should have an issue for it that provides continuity of discussion on the topic (here in this project) and it should be linked to the eventual PR. I still do not have a compelling answer as to what problem you are trying to solve other than inferring that you believe that our client tools must support some divergent ARM64 architecture (guessing M1) more quickly than the base golang compiler does. IMO, we would need the compelling argument to go down this path for not only this tool, but also for all the client tooling within the entire project that uses golang.