Adds dynamic type to _source field

[zethuman]

Description

This change adds a dynamic type to the _source field, as this field can be a boolean or string array according to the documentation. Test cases have also been added that will test this changes.

Issues Resolved

Closes [#158] .

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[Jakob3xD]

I am not yet sure what to think about the tests. I assume you create the struct to avoid duplicate code but we will lose the option to customize tests if needed, as they are static in the way how the loop runs. Maybe @dblock has a opinion on that.

Edit: Just found that such a test stile is defined in the google style guid. https://google.github.io/styleguide/go/decisions#table-driven-tests

Moreover the require does not print the error which makes it difficulty to see why a test fails. Maybe I overlooked it but I can see it locally nor in the previous failed checks.

Beside that, I would like to see a cleanup job, so you can re-run the test locally without cleaning the cluster by hand.

[zethuman]

Moreover the require does not print the error which makes it difficulty to see why a test fails.

I think this amount of information is enough for debugging?

buffer := new(bytes.Buffer)
err = json.Compact(buffer, []byte("{sadsad"))
require.NoError(t, err)

[zethuman]

we will lose the option to customize tests if needed, as they are static in the way how the loop runs.

All operations associated with api documents are approximately the same, both in the implementation example and in the fields, that is, we don’t have to come up with a lot of customization, even if we have to, it will be possible to test a separate function in the same format with this customization, or add a new one to the structure parameter if you need to test the entire api pool.

Also, I want to say that these are not finished test cases, but basic ones, in case of testing new functionality, you will not need to come up with guesses, but write cases in a table and check it, which is very convenient, since the verification logic is written. In my case, I wanted to check the work of the _source field, but since I did not find ready-made test functions, I had to write tests for the entire document. I hope this helps to further test different cases in other issues

[Jakob3xD]

I think this amount of information is enough for debugging?

Yes, I overlooked the error when testing locally.

Your tests are okay and valid. I just haven't seen this test stile before.
So no further discussion needed about the test from my side.

[zethuman]

@Jakob3xD @dblock Can someone merge this PR if there is no questions?

[dblock]

Looks good, resolve conflicts in CHANGELOG and let's merge!

[dblock]

@Jakob3xD you good with this? Merge once https://github.com/opensearch-project/opensearch-go/actions/runs/4669099913/jobs/8267090174?pr=285 passes?