[receiver/splunkhecreceiver] Updates Splunk receiver http status codes in order to be compliant with SplunkCloud

[pantuza]

Description:
TL;DR
This Pull Request makes Splunk receiver returns the same HTTP Status code as Splunk Cloud service

Problem:
SplunkCloud returns 200 OK when you send requests to /{raw/events} HTTP routes.
Splunk receiver in the other hand returns 202 Accepted. Based on that, consider a scenario
where you are migrating from sending logs to SplunkCloud directly and starting to add one
Open Telemetry Splunk Receiver in between in order to modify data before proceeding towards SplunkCloud.

The observed side effects were that all clients stopped working because the response Status Code
was different from SplunkCloud itself. Thus, such migration wouldn't be transparent.

Link to tracking Issue: N/A

Testing:
No new tests were added. Although, all previous tests were updated to use StatusOK on its assertions.

Documentation:
I didn't find any documentation regarding returning statuses codes for this particular receiver.

Examples

Event sent to Splunk Cloud directly

$> curl -v -X POST 'https://{SplunkCloudDNS}/services/collector/event' -H 'Authorization: Splunk {TOKEN}' -d '{data}'
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Date: Sat, 24 Sep 2022 19:39:22 GMT
< Server: Splunkd
< Vary: Authorization
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Length: 27
< Connection: keep-alive 

Same event sent to Splunk Receiver

$> curl -v -X POST 'https://{SplunkReceiverDNS}/services/collector/event' -H 'Authorization: Splunk {TOKEN}' -d '{data}'
< HTTP/1.1 202 Accepted
< date: Sat, 24 Sep 2022 19:44:36 GMT
< content-length: 4
< content-type: text/plain; charset=utf-8
< x-envoy-upstream-service-time: 11
< server: istio-envoy

[atoulme]

This is a good fix. I verified on the latest Splunk Enterprise as well and it does conform to replying with 200 status codes now.

[dmitryax]

@pantuza please add a changelog entry