If we want, we can also compress other values like e.g. UserIdentityTokens,
by the following additional rule:
If the UserIdentityTokens is identical to the previous UserIdentityTokens,
and the ServerCertificate was removed by the previous rule, then the
UserIdentityTokens array may be set to NULL or empty array.
However, in the unlikely case that the previous UserIdentityTokens is
non-empty and the current UserIdentityTokens is empty, this would
create ambiguity, and therefore the whole compression step including
removing the ServerCertificate shall not be done.
On the receiving side, only when the encoded ServerCertificate was
empty and the SecurityMode is not OpcUa_MessageSecurityMode_None
then an empty UserIdentityTokens means we have to re-use the previous
UserIdentityTokens value.

We could even extend this algorithm to compress all variable length fields in the
EndpointDescription structure and in the ApplicationDescription structure as well.
So all of EndpointUrl, Server.ApplicationUri, Server.ProductUri, Server.ApplicationName,
Server.GatewayServerUri, Server.DiscoveryServerUri, Server.DiscoveryUrls will usually always be the same,
so can be safely set to NULL.
And even the fields SecurityPolicyUri and TransportProfileUri may be compressed this way.

Note: while it is tempting to do the same in the ServerEndpoints field of the CreateSessionResponse,
it is probably better to stick to the compression that was suggested in part 4.