We still need an alternative to yank -- how about 'hide'?

Opening this because I think #858 was closed without understanding the point of why that issue was opened.

The changes that were made to permadelete (http://blog.rubygems.org/2015/04/13/permadelete-on-yank.html) solved issues around the usability for the use case when you really should yank a gem -- where you've pushed sensitive credentials in the gem, or it has some kind of heartbleed-level epic security hole, and you really need to delete it in order to mitigate the impact.

The problem comes when gems are yanked when they're just buggy. I ran into this before when I yanked ohai 7.6.0 awhile after it was released and broke every Gemfile.lock which had pinned ohai to that version. We also just got bit today by github_changelog_generator yanking quite a few versions that were released in the past 2 days (1.10.2,1.10.3,1.10.5,1.11.0).

As a minimum viable proposal what I'd like to suggest is a way to 'hide' a gem. When a gem is 'hidden' it should appear marked as 'hidden' instead of 'yanked' in the rubygems API. As a result of being hidden the depsolver will not use it to find solutions to constraints (failing the solve if there's no alternative). But the gem can be installed with 'gem install -v' and Gemfile.locks with hidden gems in them will still be able to pull the gem down and will not break by the action of the gem being 'hidden'.

This gets more at the use case that is often, incorrectly, what users are trying to accomplish when using 'gem yank':

• users which are happily using the 'broken' gem can still use it (presumably they're not affected by the bug)
• new users never get the 'broken' gem

I don't really think its necessary to publish the 'reason' for why the gem was hidden. Generally interested users will be able to find the reason on the issue tracker for the project. I think that all that is necessary is just implementing the 'hide' mechanism.

Start in the RubyGems repository by tracing the existing gem yank flow and the RubyGems API representation of yanked versions. Then inspect how the dependency solver and Gemfile.lock handle yanked gems; done means a hidden gem is excluded from new dependency solutions while existing locks and explicit gem installs still work.