rust_binary with crate_type = cdylib doesn't produce expected providers

[keith]

We have a rule like this:

    rust_binary(
        name = ...,
        edition = "2018",
        crate_type = "cdylib",
        out_binary = True,
...
    )

which since 5abeb93 (in release 0.4.0) fails with:

ERROR: /Users/ksmiley/dev/envoy/test/extensions/common/wasm/test_data/BUILD:12:17: in rust_binary rule //test/extensions/common/wasm/test_data:_wasm_test_rust_wasm:
/private/var/tmp/_bazel_ksmiley/4096f01a2eae006dd7eb0d708a9f3935/external/rules_rust/rust/private/rust.bzl:295:5: rule advertised the 'CrateInfo' provider, but this provider was not among those returned
ERROR: /Users/ksmiley/dev/envoy/test/extensions/common/wasm/test_data/BUILD:12:17: Analysis of target '//test/extensions/common/wasm/test_data:_wasm_test_rust_wasm' failed
ERROR: Analysis of target '//test/extensions/common/wasm:wasm_vm_test' failed; build aborted:

It looks like the issue is that rust_binary still states that it will create CrateInfo yet it does not in this case. Our use case doesn't seem to care about this, so just removing that requirement is enough. This is reproducible on this branch envoyproxy/envoy#21208 with bazel build --nobuild //test/extensions/common/wasm:wasm_vm_test --define=wasm=wamr.

[keith]

Potential fix #1331

cc @scentini

[scentini]

I think rust_binary shouldn't provide a CrateInfo, but one should still be able to depend on a rust_binary from rust_test.crate. So we could instead provide a TestCrateInfo, like we now do for rust_static_library and rust_shared_library.
I can prepare a PR for this early next week, unless someone beats me to it :)

[keith]

I think that works already in the change I linked above, it just wasn't declared that way before, so bazel fails

[PiotrSikora]

This is fixed in #1315 (once it's merged).

[scentini]

@keith I meant also for the regular crate_type = "bin" rust_binary targets. I have #1339 which is close to ready for review and should resolve this.