Fix git SHAs comparison for update.

[alinpopa]

Let me give you a bit of a context here:

• I found this while I was trying to use a test dependency which is not being locked;
• tried to remove this restriction https://github.com/erlang/rebar3/blob/master/src/rebar_prv_install_deps.erl#L383 and see what's happening;
• the version for my test dependency was set to a 7 chars short SHA;
• noticed that the comparison was always happening between the fully long SHA and the short SHA provided, hence it'll always return true for needs_update, and that means it'll always try to fetch the source for the dependency;
• this can be tested as well with a custom plugin hosted on github (see https://github.com/alinpopa/test_git_short_sha as an example for this)

Conditions to replicate this issue:

• make sure you have a dependency that is not locked by rebar3 (I used meck as a test dependency in https://github.com/alinpopa/test_git_short_sha);
• make sure you use a short (7 chars) SHA ref;
• make sure the is_lock restriction is removed from https://github.com/erlang/rebar3/blob/master/src/rebar_prv_install_deps.erl#L383, otherwise not being locked, this dependency will always be skipped.

Some other things I've considered while having this issue:

• why that is_lock restriction in place? if the responsibility of needs_update will stay entirely within the resolver, would that restriction still be needed?
• test dependencies and plugins are not locked, and this makes it quite hard to refresh the code for those using the resolver - is there any plan of addressing these sort of things?

[talentdeficit]

is this to allow backwards compatibility with older lock files? i think i'd prefer if we forced users to explicitly update the lock file but i'm not sure how strongly i prefer that

[tsloughter]

Doesn't it need to sublist it because the user can put any ref they want in the rebar.config? So it isn't an issue for the lock file, but it is for what the user may put in their on dep list.

[alinpopa]

If these are questions for me, I believe the answers are based on some historical context that I'm not aware of; all I can say, is that the code the way it is, doesn't seem to work properly.

[ferd]

@talentdeficit @tsloughter are you both okay with merging this? It's been there a while and it looks okay by me.

[tsloughter]

Yea, this looks good.