fix: 2FA password visibility toggle show/hide state

[Chiranjeev-droid]

What does this PR do?

Previously, when users attempted to enable two-factor authentication (2FA) on our platform, they encountered an issue with the password visibility toggle. Specifically, when they entered their current password for confirmation, it remained hidden, making it difficult to verify the input. However, with the recent code update, I have addressed this usability concern. Users can now see and toggle the visibility of their current password when confirming their choice to enable 2FA. This improvement enhances the overall user experience, making the process smoother and more intuitive.

Loom Video:
Before change :- https://www.loom.com/share/Profile-or-Calcom-14-September-2023-bb68faf8d15449f796f2ff3782a7825e?sid=ad9c41e0-0f20-4985-9a7f-217f6472775d

After Making change

https://www.loom.com/share/Two-Factor-Authentication-or-Calcom-14-September-2023-1ac49793c94f4ed9a8e19489d0b95458?sid=afe90a92-892a-4061-b007-64be4b4a2454

Type of change

• Bug fix (non-breaking change which fixes an issue)

How should this be tested?

1. Open your cal account
2. Go to settings tab to enable 2FA under security tab of settings sidebar.
   3.For enabling 2 factor auth, enter your password and click on eye icon to view your password and you wont be able to see.
3. After this pr changes gets merged, we can easily toggle the visibility of password.

Mandatory Tasks

• Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

[vercel]

@Chiranjeev-droid is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 14, 2023 0:40am

[github-actions]

Thank you for following the naming conventions! 🙏

[github-actions]

📦 Next.js Bundle Analysis for @calcom/web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

Five Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load	% of Budget (350 KB)
/apps/installed/[category]	259.99 KB	415.47 KB	118.71% (🟡 +0.20%)
/availability	275.27 KB	430.75 KB	123.07% (🟢 -28.27%)
/availability/[schedule]	339.99 KB	495.48 KB	141.56% (🟢 -0.45%)
/bookings/[status]	332.21 KB	487.69 KB	139.34% (🟡 +0.20%)
/getting-started/[[...step]]	388.54 KB	544.02 KB	155.43% (🟡 +0.30%)

Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

[hariombalhara]

Thanks @Chiranjeev-droid 🙏 Nice fix!!