Remove ORIGIN header from ws opening handshake v13, clean up code

[amizurov]

Motivation:

In Netty 5 we only left the latest 13 version of websocket, so we can clean up the code a bit.

Modification:

• Remove origin header from handshake request, it can be set with customHeaders, see Origin header is always sent from WebSocket client #9673
• Calculate expected value of sec-websocket-accept only when we received a response
• Remove unused code
• Add more tests for clientHandshaker13

Result:
Removed not used code and fixed wrong behaviour with origin header #9673.

[amizurov]

@chrisvest @normanmaurer could you please take a look.

[chrisvest]

The Graal build is failing with

2022-04-07T16:15:48.7340933Z Error: Classes that should be initialized at run time got initialized during image building:
2022-04-07T16:15:48.7343421Z  io.netty.util.internal.PlatformDependent was unintentionally initialized at build time. To see why io.netty.util.internal.PlatformDependent got initialized use --trace-class-initialization=io.netty.util.internal.PlatformDependent
2022-04-07T16:15:48.7344128Z 
2022-04-07T16:15:48.7344721Z Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
2022-04-07T16:15:48.7695521Z Error: Image build request failed with exit status 1

I don't see anything in the changes that would pull in the 4.1 version of PlatformDependent, but we did have a problem like that a while back, so maybe a rebase will fix it.

[chrisvest]

Looks fine for me, but I also want Normans review before merging.

[chrisvest]

Not sure what the consensus is on using the var keyword.

[amizurov]

I don't think that for using var exists strict guidelines or something like this.
When i prefer use :

• type explicitly mentioned in initializer (var request = new DefaultFullHttpRequest(..), var bytes = new byte[10])
• return type is well known (var status = httpResponse.status(), var headers = httpResponse.headers(), ..)
• qualified static method (var statusCodes = List.of("1xx", "2xx", "3xx", "4xx", "5xx"))
• type casting ( if (msg instance of HttpObject) var httpObject = (HttpObject) msg)
• it can make the line shorter because we have a limit of 120 characters.
  But if you think that this is inappropriate here, I can remove var in hole PR.

[doom369]

Here is a good guide - https://res.cloudinary.com/snyk/image/upload/v1524742320/Local_Type_Inference_Cheat_Sheet_for_Java_10_and_beyond_web.png

[amizurov]

@doom369 thanks, good guide and It's looks similar with my list, also i never use var for base types (int, byte, .....). By the way, again if you think not use var at all in our code i can remove, no problem here. Or we can approve some cases in its use and follow them otherwise as I mentioned there are no strict rules and each contributor will do it in his own way. @doom369, @hyperxpro, @chrisvest, @normanmaurer WDYT ?

[chrisvest]

I'd be fine with following the guidelines of that cheat sheet.

[doom369]

also i never use var for base types (int, byte, .....).

Same here, also I never do that for the method returns, like in this particular example, as it always complicates the code reading, even the variable name seems super straightforward, type is not clear.

[amizurov]

Fixed, according guidelines.

[hyperxpro]

As @chrisvest mentioned, let's refrain from using var because it doesn't give the exact object type.

[hyperxpro]

Revert

[amizurov]

Left as is

[hyperxpro]

Revert because no one is going to initialize this class except us.

[amizurov]

If you think it's redundant, I can remove it. But for me it's more clear in utility classes.

[amizurov]

Removed