Investigate whether webhook verification should be used on deauthorize route

[mickmister]

For the deauthorize feature, we are checking the legacy webhook secret, but not performing the newer webhook verification.

The task here is to investigate the deauthorize call, to see if the Zoom webhook verification information is in the HTTP headers. See #279 for more details on the webhook verification requirements.

mattermost-plugin-zoom/docs/installation/zoom-configuration/zoom-setup-oauth.md

Lines 44 to 53 in 229517f

	## Deauthorization
	This plugin allows users to be deauthorized directly from Zoom, in order to comply with Zoom’s commitment to security and the protection of user data. If you **would like to publish on Zoom Marketplace**, you can set up a deauthorization URL.
	1. Select **Information**.
	2. Near the end of the page, is a section called **Deauthorization Notification**.
	3. Enter a valid **Endpoint URL** \(`https://SITEURL/plugins/zoom/deauthorization?secret=WEBHOOKSECRET`\).
	* `SITEURL` should be your Mattermost server URL.
	* `WEBHOOKSECRET` is generated during [Mattermost Setup](../mattermost-setup.md).

Originally posted by @mickmister in #279 (comment)

[raghavaggarwal2308]

@mickmister I explored a bit on this issue and have some findings. If we go through the official Zoom documentation of Deauthorization, it's not specifically mentioned that we can use the new webhook validation or not but they have provided us the link to the page of webhook validation.

I tried to get the deauthorize request notification from Zoom to verify if the x-zm-signature required for webhook validation is present in the headers or not but I was unable to install the Zoom oauth app to production, so I was unable to get the deauthorization notification on MM.

I found this issue in which a user is saying that he is unable to match the signatures while performing the validation for deauthorization request. So according to this the header is present in the request.

[mickmister]

@raghavaggarwal2308 I'm thinking we should just not worry about this. We already have our own mechanism (our webhook secret) to determine the validity of the request.

[mkdbns]

Thanks for the feedback @mickmister . Will you close this issue then?