Mk/Uses/cargo.mk: Use canonical crate file extension going forward

[tobik]

Summary

Crates should have the file extension .crate not .tar.gz. Cargo
saves them with that extension and it is also what their original
name was according to file(1):

$ file rust/crates/*
rust/crates/better-panic-0.2.0.tar.gz:gzip compressed data, was "better-panic-0.2.0.crate"
rust/crates/binary-space-partition-0.1.2.tar.gz:gzip compressed data, was "binary-space-partition-0.1.2.crate"

The only reason we used .tar.gz is that it was that way in OpenBSD's
devel/cargo/cargo.port.mk module.

Test Plan

make checksum of affected ports was fine. Test builds of devel/tokei and shells/starship were also fine.

[tobik]

• Change approach and do it in a backwards compatible way instead

I do not like what I did previously. Also a bit wary of making cherry picks to 2021Q2 harder and invalidating uncommitted port submissions and updates. I came up with something that should do this in a backwards compatible way and ports can slowly transition over. This also needs to be committed to 2021Q2 to not break cherry picks later.

@portmgr Is something like this acceptable?

[tobik]

Any opinions on this approach?

[jbeich]

• Switching to .crate seems OK and aligns with PkgSrc
• Converting both main and 2021Q2 (a la f90ccf6cfccc) can avoid the delay:
  • Mirrors will keep only .crate instead of both .tar.gz and .crate
  • [rare case] No dependency on port update when cherry-picking an unrelated crate bump

[tobik]

In D29760#672237, @jbeich wrote:

• Switching to .crate seems OK and aligns with PkgSrc
• Converting both main and 2021Q2 (a la f90ccf6cfccc) can avoid the delay:

So IIUC you would prefer a full conversion once over a delayed one?

• Mirrors will keep only .crate instead of both .tar.gz and .crate

Hmm, hadn't thought about that. All crates combined seem to be < 600 MiB. I think it would be acceptable to keep both around for a while.

$ rg -g 'distinfo' -I 'SIZE \(rust/crates/' | sort -u | awk '{sum += $4} END{print sum/1024/1024}'
575.011

• [rare case] No dependency on port update when cherry-picking an unrelated crate bump

Possible but very rare case IMHO ;-)

These are all valid point but doing a full conversion still invalidates all external ports from Bugzilla, custom overlays, WIP updates, etc. and might cause unnecessary extra work for others. That's the hangup I currently have. I'm probably overthinking it.

[Note to self: if full conversion add something to CHANGES]