Re-sign composer metadata when drupal.org metadata is updated [#3582535]

Problem/Motivation

If a new version of a package is released, we normally expect the composer metadata JSON to increase in size with each new release.

With some packages, we are seeing an invalid sha256 hash error for composer metadata JSON targets, for example:

  [Tuf\Exception\Attack\InvalidHashException]                                
  Invalid sha256 hash for files/packages/8/p2/drupal/lti_tool_provider.json

In these cases, the expected size of the composer metadata JSON either stays the same or decreases (so we aren't seeing #3582527: Validate that new releases have been added as TUF targets because we are within the limit).

Steps to reproduce

To set up, see steps to reproduce in #3579174: [meta] Diagnose issues related to TUF-enabled projects. To figure out the hash of a given target, see #3579174-13: [meta] Diagnose issues related to TUF-enabled projects.

Test requiring any of:

drupal/better_field_descriptions
drupal/ckeditor
drupal/cms_blog
drupal/lti_tool_provider
drupal/mailjet_webform_subscription
drupal/shariff
drupal/smart_ip
drupal/views_linkarea
drupal/weight

Expected result: Requiring the package succeeds, assuming there is a valid version matching your Drupal install.

Actual result is an error similar to:

  [Tuf\Exception\Attack\InvalidHashException]
  Invalid sha256 hash for files/packages/8/p2/drupal/lti_tool_provider.json

Proposed resolution

Our hypothesis is that the only way that the composer metadata can have a different hash but not increase in size would be through changes to drupal.org metadata, since it appears that sections such as author are populated from drupal.org metadata.

If this is in fact the case, then a potential resolution would be to send the new composer metadata for signing when drupal.org metadata is updated.