[processor/remotetapprocessor] don't require Origin header

[seankhliao]

Description:

Currently remotetap runs a server using websocket.Handler
This internally creates a websocket.Server
that requires a Origin header in the incoming request.
While this makes sense for browser usage,
for the collector we may want to use other tools e.g. CLI tools which do not set an Origin header.

This changes the server to use websocket.Server directly, without setting Handshake,
bypassing the origin check

Link to tracking Issue: N/A issue reported in slack

Testing: manual https://cloud-native.slack.com/archives/C01N6P7KR6W/p1724957510485869?thread_ts=1724863668.431979&cid=C01N6P7KR6W

Documentation: none / bug fix

[atoulme]

Could the user not use the server CORS settings to make sure the server is configured for the proper use case?

https://github.com/open-telemetry/opentelemetry-collector/tree/main/config/confighttp#server-configuration

Can you please add a test?

[seankhliao]

no, cors in confighttp returns a header that allows the client to check in a preflight request if it is allowed to make a proper request. This is a server side check that the client includes an Origin header, which cli tools don't set (nor do they make preflight cors checks because cross origin isn't a concept that applies to a cli not run from a web origin).

I'm not sure how to add a test, the go websocket client in use requires an origin to be provided to work (which may not be true of other websocket libraries).

[j-kap-t]

Confirmed this fixes the 403 forbidden issue I was having with the websocat CLI.

[atoulme]

Please add changelog and let's get it in.

[seankhliao]

added a changelog entry

[MovieStoreGuy]

Is there any tests that help confirm this behaviour or a regression isn't added in?

[seankhliao]

like I mentioned earlier in the pr thread, there's no easy way to test it unless we want to pull in another websocket library?