I am trying to prevent user information leak or rainbow table attack
To prevent usage of rainbow tables, it is sufficient to use random long salt, e.g. 128 bit salt.
One of the links you mentioned, Asymmetric Cryptography as Hashing Function
explains well disadvantages of using asymmetric cryptography for password hashing. In particular, password verification can be much faster than compared to Argon2. Means, brute-forcing can be much easier compared to Argon2.
To make brute-forcing impossible, verification of each password needs to be expensive. The algorithms like Argon2 can be configured so that verification of a every single password requires much more CPU and RAM than fast algorithms like SHA1.
That's why I'd suggest you to consider Argon2. If it is not available for you (e.g. because your customer does not allow some algorithms), consider using bcrypt, scrypt, PBKDF2.
Making an algorithm complex does not make it secure.
In the algorithm you use salt. But on the last step you only save the public key. This is not sufficient. You need to save also the salt, otherwise it will not be possible to verify passwords later on.
The only reason your algorithm is resistant to rainbow tables is the usage of salt (provided that you use it properly, i.e. you save the salt together with public key). If you remove salt, your algorithm will not be resistant to rainbow tables.
Your algorithm will be very fast. This means that brute-forcing your algorithm will be much easier for an attacker compared to properly configured password derivation algorithms like Argon2. Suppose checking of a single password with your algorithm takes 1 / 1 000 000 s and 1 K RAM. Suppose some other application uses Argon2 to hash password and hashing of a single password takes 1 s and 1 MB RAM. This means, to brute-force your database with hashed passwords an attacker will need 1 000 000 less CPU power and 1000 times less memory, means an attacker will need way less money and less time to brute-force your hashes compared to Argon2 hashes.
Despite brute-forcing of really random passwords will still be hard, it will make sense for an attacker to at least do a dictionary attack, i.e. some set of words and some common modifications of these words. Suppose an attacker takes 100 000 words and 1 000 000 modifications for each word. Thus there would be 10 000 000 000 passwords to test. If your check takes 1 / 1 000 000 s, this would take 100 000 s which is about 28 h on a single computer. If the attacker has money to rent 1 000 virtual machines for 10 days, then this will allow to test even more modifications of dictionary words. This means that at least dictionary attack may be successful.
What can you do? Use some password derivation algorithm that is resource expensive, e.g. Argon2. Configure it so that a single test takes 1 s and say 1 MB RAM on your server.