(Review) Modify Send-/Recv-buffer handling + MaxMsgSize (from PR 2955)

[mlang-de]

See discussion in pull request #2955

[mlang-de]

Current commit:
The between client and server shared function UA_SecureChannel_processHELACK is splitted into UA_SecureChannel_serverProcessHELACK and UA_SecureChannel_clientProcessHELACK.
This is imho required since the server shall never return a bad status during HEL-Msg.
The server shall response with the revised channel configuration the server can support.
The client shall check whether it can handle these revised configuration.

I am not the client guy, so someone with client expertise is asked to look into the UA_SecureChannel_clientProcessHELACK function.

[jpfr]

I understand that there are some differences in the client and server-side handling.
But we should keep as much logic common as possible.
Can we have a function with the common subset of the HEL logic and both the client and server side call into that?

[mlang-de]

Imho there are no real common parts which can be used for both.
Maybe a additional function parameter which indicates which kind of checks (sever or client) are required.
But within the function different logic will be used.
For instance:

UA_StatusCode
UA_SecureChannel_ProcessHELACK(UA_SecureChannel *channel,
                               const UA_TcpAcknowledgeMessage *remoteServerConfig, uint8_t fServerOrClient)
{
    if(fServerOrClient == Server)
    {
        /* do checks from function UA_SecureChannel_serverProcessHELACK */
    }
    else
    {
        /* do checks from funtion UA_SecureChannel_clientProcessHELACK */
    }

    return UA_STATUSCODE_GOOD

Some checks could maybe merged and reused.

• MaxSendBuffer or MaxReceiveBuffer

BUT so the client side never uses a bad statuscode and the client must be able to handle each channel configuration revised from the server. This ends up, that a client has to support unlimited resources each time.

[lgtm-com]

This pull request introduces 1 alert when merging ab3ab96 into 0af95df - view on LGTM.com

new alerts:

• 1 for Implicit function declaration

[lgtm-com]

This pull request introduces 1 alert when merging b95458a into 0af95df - view on LGTM.com

new alerts:

• 1 for Implicit function declaration

[mlang-de]

@jpfr Please confirm, that this PR is ok in relation to 1.2 rebasing. I do a lot squash, rebase and so. Not sure that this PR is now "clean" or "ok". Tests outstanding.