Inconsistent implementation for MQTT 5 persistent sessions (clean_start)

# Bug Description

I have noticed the python client uses `clean_start=False` for MQTT 5 connections on reconnecting if `clean_start` is not set by the user in the `connect()` method. This is caused by `clean_start` being optional and using MQTT_CLEAN_START_FIRST_ONLY as a default. At the same time the value for session expiry interval is not set or checked leading to possible `0` length interval. Even though this is a valid setting it is a contradictory combination as in this case no session is stored on the broker. The MQTT 5 specification defines the following for session expiry:

> If the Session Expiry Interval is absent the value 0 is used. If it is set to 0, or is absent, the Session ends when the Network Connection is closed.

I don't understand the reason behind this implementation as from a user point of view it makes no sense to me. I either want persistent sessions (`clean_start=False`) or I don't (`clean_start=True`). The implementation can lead to unwanted / undefined behavior though.

This does also have implications for the broker as this potentially creates unwanted overhead. Creating persistent sessions can involve disk I/O operations as messages sent with QoS greater 0 need to get queued.

# Reproduction

Connect to a broker using MQTT 5 w/0 setting `clean_start` in the connect method. Check connection parameters for client connection. `clean_start` is set to `True`. Do a server side disconnect and force the client (same instance) to reconnect. Check the client connect and see `clean_start` set to `False`.

# Possible Solutions

From my POV there are these possible solutions ordered by favor:

1. Make `clean_start` non-optional and forcing the user to set a defined value
2. Set `False` or `True` to be the default value
3. Keep current logic but set sessions expiry interval to a value greater than zero

# Environment

* Python version:
* Library version:
* Operating system (including version):
* MQTT server (name, version, configuration, hosting details): HiveMQ Enterprise 4.35

# Logs