Expose composer error message when not resolvable

[jeffwidman]

Expose the underlying composer error message when a dependency is not resolvable.

While debugging a customer issue, we ran into the problem that the error output from the composer helper was being swallowed:

dependabot-core/composer/lib/dependabot/composer/update_checker/version_resolver.rb

Lines 295 to 304 in b911f9d

	elsif error.message.include?("requirements could not be resolved")
	# If there's no lockfile, there's no difference between running
	# `composer install` and `composer update`, so we can easily check
	# whether the existing requirements are resolvable for an install
	check_original_requirements_resolvable unless lockfile
	# If there *is* a lockfile we can't confidently distinguish between
	# cases where we can't install and cases where we can't update. For
	# now, we therefore just ignore the dependency.
	nil

The underlying error:

Your requirements could not be resolved to an installable set of packages. (Dependabot::SharedHelpers::HelperSubprocessFailed)
  Problem 1
    - php-amqplib/php-amqplib v2.11.3 conflicts with php[7.4.0].
    - php-amqplib/php-amqplib v2.11.3 conflicts with php[7.4.0].
    - Installation request for php 7.4.0 -> satisfiable by php[7.4.0].
    - Installation request for php-amqplib/php-amqplib (locked at v2.11.3, required as ^2.6) -> satisfiable by php-amqplib/php-amqplib[v2.11.3].

Swallowing the error makes it hard for users to figure what's going on.

The original motivation for swallowing was in the early days of Dependabot Preview, it opened issues for exceptions raised in the updater/core which has forced us to suppress certain errors that might be spammy or intermittent, e.g. resolvability errors. In version updates we no longer create issues so attaching errors to the last update job means we can attach any number of errors to highlight potential issues without spamming users.

Fix #6289

[jeffwidman]

Putting this on ice for a bit to brainstorm possible ways to handle when missing PHP native extensions as mentioned in #6289 (comment)

[jeffwidman]

We can probably switch this to logging the error message, so it's still visible in the job logs, but doesn't actually fail the job due to the problem mentioned in #6289 (comment)

[jeffwidman]

Uh, thanks for the review/approve, but we don't want to merge this as-is... see the comment thread above.

[robaiken]

I have opened a new PR to resolve this, so I am closing this PR: #9657

[jeffwidman]

That's awesome you're tackling it!

However, let's not actually close PR's until another PR is actually merged... because my experience is not all PR's get merged, and then we end up with a world of forgetting to re-open an original PR that may be halfway done.

☝️ is a general best practice that I see followed in most open source repos, not specific just to this PR.