Sync plugin metadata info fields during plugin update

[cibere]

When an update is detected in the auto updater, the manifest's copy of the plugin's metadata doesn't get its information keys synced with the plugin's plugin.json file, leading to outdated descriptions, urls, authors, etc.
see all of the plugin files that I updated in this PR because they had out-of-date info

This PR adds code that fetches the plugin's plugin.json file when an update is detected, and updates the following fields:

• Description
• Author
• Language
• Website

Note: Two plugins will error with this due to a typo with their Description keys. I've created PRs on their repos to fix this (CursorWorkspace and VSCodeWorkspace)

[jjw24]

This is fine for now since we don't get too many plugin updates per run. We might need to revisit this in the future to separate the metadata updates out on its own and implement the same etag checking (if possible) to avoid doubling up the GitHub API requests during updates.

[cibere]

This is fine for now since we don't get too many plugin updates per run. We might need to revisit this in the future to separate the metadata updates out on its own and implement the same etag checking (if possible) to avoid doubling up the GitHub API requests during updates.

I don't understand how that would help, since the second request to the github api only happens when an update is detected, my understanding is that the current etag system will stop the function if a new update isn't detected before it reaches the new code, and even if it doesn't, there is a version check to ensure that its a new update

[jjw24]

Using etag will send a conditional request, which doesn't count against the API limit if content is the same (it returns 304 instead of retrieving the requested result). So updating metadata based on etag is ideal in the future when plugin updates occur a lot more, and for right now since there aren't many instances where plugin actually is updated in one run it's ok to send an API request for release info and another to download the zip file.

[cibere]

Using etag will send a conditional request, which doesn't count against the API limit if content is the same (it returns 304 instead of retrieving the requested result). So updating metadata based on etag is ideal in the future when plugin updates occur a lot more, and for right now since there aren't many instances where plugin actually is updated in one run it's ok to send an API request for release info and another to download the zip file.

Ah ok, I think I understand now.

Anyways, I believe I've fixed the problem you mentioned in your review

[jjw24]

This function name batch_github_plugin_info really confuses me- is it the current plugin info or new updated info? Everytime I read this I need to think twice what context this is in... Next time if you happen to change this part of the code please do me a favour and update this name to something better describe this functionality e.g. get_updated_batch_plugin_info 🙏