update elastic-agent-shipper-client deps

[fearful-symmetry]

What does this PR do?

This updates the elastic-agent-shipper-client deps to pull in the recent bugfixes.

Why is it important?

This upstream change fixes a number of bugs.

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @fearful-symmetry? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[fearful-symmetry]

Alright, CI errors appear to be actually related, looking over them...

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-02-24T20:51:37.771+0000

• Duration: 46 min 36 sec

❕ Flaky test report

No test was executed to be analysed.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[fearful-symmetry]

Alright, I'm not 100% sure if some of these errors. The "returns error if failed to convert metadata" and "returns error if failed to convert fields" tests now return an event with the fields {"field":{}} and I'm not sure if we need/want that to be an error condition? It looks like a few other tests are also failing because we're expected to error out on empty objects. Should that be an error condition? @cmacknz

[cmacknz]

{"field":{}} is valid JSON so it should not be an error. We should correctly serialize and pass this through. It is entirely possible we are trying to ship a response from an external API that includes an empty JSON object in its response.

The protojson package serializes the message to the structure below which is syntactically valid JSON for example:

            {
              "timestamp": "2023-02-16T18:54:25Z",
              "source": {},
              "dataStream": {},
              "fields": {
                "data": {
                  "field": {
                    "structValue": {}
                  }
                }
              }
            }

[fearful-symmetry]

Yah, that's what I thought, just wanted to make sure.

[fearful-symmetry]

Want to update the PR with fixes before the long weekend, but right now we're in a weird state where we're not testing certain things like retries/dropped events, since the marshaling code is much more aggressive with not erring out. Will have to re-do some of the mock shipper server so I can get events to drop.

I also suspect that since the event marshaler is more capable of handling map types, there might be some redundant code. Not sure if we want to deal with that in this PR or do a follow-up.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b shipper-client-update upstream/shipper-client-update
git merge upstream/main
git push upstream shipper-client-update

[fearful-symmetry]

/test

[fearful-symmetry]

/test

[fearful-symmetry]

E2E failures are unrelated, merging