Allow MQTT Client negotiation of CONNECT packet properties

[rcoppen]

Describe the bug

The AsyncAPI MQTT bindings spec allows the server to assert certain values such as ClientId. Since a ClientId will be unique to each client instance for a given server endpoint, it would be the Client's responsibility to supply its unique ClientId as part of its CONNECT operation. It's unclear in the current AsyncAPI binding how the value of ClientId should be interpreted. The same is true for other property values e.g.,CleanSession Will Topic and Will Message. For example, in the case of CleanSession the client would typically calculate this based on its state. If the AsyncAPI MQTT binding doc presents true does the client have to always connect with this value or is it a server asserted starting point?

How to Reproduce

The MQTT binding is available here > https://github.com/asyncapi/bindings/tree/master/mqtt <

Expected behavior

It should be clear to the consumer of the AsyncAPI MQTT binding document that the MQTT client application must specify a unique clientId value for each app instance. It's not clear which version of MQTT the binding applies to. Assuming 3.1.1 (OASIS standard) then the default behaviour could be set to not present which would request the server to create a new ClientId. In the case of the other options such as Will Message one approach would be to present this in a way that indicates if the service endpoint provides support for this as a hint for the client to include on their CONNECT packet.

[dan-r]

There seems to be similar issue for the Kafka (with clientId) and AMQP (with userId) bindings. There isn't a clear distinction between enforced service properties and recommended(?) client options. I'd argue that client properties like this aren't always especially useful for a service spec as they could vary massively between clients of the same service.
Eg: a cellular client going through a 20 mile tunnel will likely have different parameters to a static client in an office.