is the public key sent by server encrypted or clear? I assume it is clear since it is public
The public key of the server is contained in clear in the server certificate which is send in clear by the server, which means that the public key is implicitly send in clear too. Note that this is only the case with certificate based server authentication which is the most common way to authenticate the server in TLS but not the only one. Other ways to authenticate the server are for example pre-shared keys (PSK) where no public keys are involved at all.
How are the session key and public key related?
The result of the key exchange is a pre-master secret which then gets used to derive a master secret which then gets used to derive the session keys, i.e. the keys to encrypt and protect (HMAC) the application data.
If Diffie-Hellman key exchange is used as you state then there is no relation between the public key and the pre-master secret and thus not between the public key and the session keys. The only use of the certificate in this case is to authenticate the server and it plays no role in the key exchange. Diffie-Hellman key exchange can also be used for TLS handshakes where no public key is involved at all, for example with PSK authentication.
Does the client sends session key to the server? session key sent: f(Random_gen_number, Public_key) where f is an encryption function?
With Diffie-Hellman key exchange there is nothing even similar to this. With RSA key exchange the client instead creates the pre-master secret fully on the client side (i.e. it is not a result of a key exchange where both parties are involved, like in DH key exchange) and sends it to the server encrypted with the public key of the server. The server then decrypts this with its (secret) private key and thus can extract the pre-master secret. The process of deriving the master secret and the session keys from this is then the same as with DH key exchange.
This process of sending the pre-master secret to the server also means that knowledge of the servers private key allows to retrieve the pre-master secret, derive the session keys and decrypt all traffic. This is true even for older traffic if the traffic was captured at some time and the attacker or secret service got access to the private key only later. Contrary to this with DH key exchange no actual exchange of the pre-master secret happens but instead it is derived on both sides. Having access to the private key of the server will not allow an attacker to decrypt the sniffed traffic, i.e. an active and real-time man-in-the-middle attack is instead needed. That's why DH key exchange is the preferred one today and the only one support starting with TLS 1.3.
