Remove check for stale database that is no longer effective

[mikesaelim]

I thought I'd clean up some stuff around the advisory database, so this PR does 3 things:

Remove the check for stale database

The first thing is removing the check_for_stale_database, because I don't think it does anything anymore.

It looks to me like, when this gem was originally written on top of bundler_audit v0.4.0, bundler_audit was vendoring the advisory database in a data/ruby-advisory-db folder. When the user runs a check, bundler_audit chooses the most up-to-date of either this vendored copy or the user's local copy (at ~/.local/share/ruby-advisory-db) if it exists. RubyAudit's Database inherits this behavior.

However, at that time, bundler_audit v0.4.0 was vendoring an old copy of ruby-advisory-db that hadn't begun to include ruby and rubygems vulnerabilities yet. So, RubyAudit had this check_for_stale_database, to ensure that the database it was using had been updated to a new enough version. Nowadays, bundler_audit no longer vendors the database at all, and just uses the user's local copy. RubyAudit's Database inherits this behavior. Any database it could download will be well past the point in time that this check is trying to avoid.

Print out when the database was last updated

I noticed that bundler_audit does this now, so I figured why not do it too?

Add clarification to the README about our vendored database

This repo also vendors a copy of ruby-advisory-db in the vendor folder, and every time I come back to this project, I'm always confused about it. So I added a note to the README for future me (and future everyone) that the vendored database is only used for our specs and is not used by the live code.

What do you all think?

[leanne73]

LGTM!