Improves not found response handling in the saved objects repository

[TinaHeiligers]

Resolves #107343

This PR is to address the follow up on #107301, and verifies that 404 responses are from ES in the remaining saved object repository APIs where we explicitly ignore 404 and handle the error ourselves.
If the check fails, we throw a decorated EsUnavailableError instead of Not Found.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

Risk Matrix

Risk	Probability	Severity	Mitigation/Notes
False positives— An intermediate proxy doesn't forward x-elastic-product header .	Low	Low	As of 7.15.0 Kibana won't start unless the required headers are present. For 7.14 patches, the type of error returned could be a 404 or a 503 but we will still get an error

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[TinaHeiligers]

I'm in two minds about where this helper should go and considered moving it to the elasticsearch service but went with internal_utils as we're really only using it within the SO service right now.

I'm also open to suggestions for the name (naming is hard...)!

[lukeelmers]

FWIW, I don't have strong feelings one way or the other on whether this is internal or in the ES service. If it was used anywhere else I'd say put it in the ES service though.

[TinaHeiligers]

I moved the method since we're both thinking it should belong to the elasticsearch service. While ATM it's only used in the SO service, other folks might have to implement something similar.

[lukeelmers]

Overall makes sense! Couple thoughts & questions.

[lukeelmers]

FWIW, I don't have strong feelings one way or the other on whether this is internal or in the ES service. If it was used anywhere else I'd say put it in the ES service though.

[lukeelmers]

nit: If we aren't including the ES product header here, might be worth renaming this function for clarity so that it is obvious it is specific to only one type of error?

Or I guess alternatively you could attempt to make it more generic by, say, adding an expectedErrorResult as in bulkCreateError and conditionally exluding the header if the error is a genericNotFoundEsUnavailableError

Same nit applies to bulkGetMgetError and bulkUpdateMgetError

[TinaHeiligers]

might be worth renaming this function for clarity so that it is obvious it is specific to only one type of error

I went with the renaming option (e.g. https://github.com/elastic/kibana/pull/108749/files#diff-8a58e602e79e19512cd392387f38a79ba9782f60d0fc1596a90d5e9e18efb6bdR655) to make it super clear!

[lukeelmers]

Updates LGTM

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 810fbdc
• Storybooks Preview

Metrics [docs]

✅ unchanged

History

• 💚 Build #145991 succeeded 0cb74e0
• 💔 Build #145985 failed 3651a2e
• 💚 Build #145867 succeeded 6def7f8
• 💚 Build #145861 succeeded 0196166
• 💔 Build #145831 failed bb1dfa2

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kibanamachine]

💔 Backport failed

Status	Branch	Result
✅	7.x
❌	7.16	The branch "7.16" is invalid or doesn't exist

Successful backport PRs will be merged automatically after passing CI.

To backport manually run:
node scripts/backport --pr 108749