Remove erroneous reference to the base Symbol when mapping Rust types

[david-perez]

.addReference(this) adds a reference to the Symbol on which
.mapRustType was called. This is correct only when f is a function
that wraps its input RustType; for example, when f wraps it in a
Box or constructs a Vec. However, the code is incorrect for an
arbitrary f; for example, when f swaps the type.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python

A new doc preview is ready to view.

Rust Wrk benchmark report:

Duration: 90 sec, Connections: 32, Threads: 2

Measurement	Deviation	Current	Old
Requests/sec	-10.11%	33417.07	37176.31
Total requests	-10.15%	3007910	3347793
Total errors	NaN%	0	0
Total successes	-10.15%	3007910	3347793
Average latency ms	8.89%	0.98	0.9
Minimum latency ms	0.00%	0.03	0.03
Maximum latency ms	21.80%	21.06	17.29
Stdev latency ms	-1.69%	0.58	0.59
Transfer Mb	-10.15%	312.67	348
Connect errors	NaN%	0	0
Read errors	NaN%	0	0
Write errors	NaN%	0	0
Status errors (not 2xx/3xx)	NaN%	0	0
Timeout errors	NaN%	0	0

[rcoh]

do you think this should just use symbol.toBuilder() instead of making a new symbol? We probably want to preserve symbol references—those are use for nested dependencies. We could also make this method private and only use it in the mapping use cases you described

[david-perez]

do you think this should just use symbol.toBuilder() instead of making a new symbol? We probably want to preserve symbol references—those are use for nested dependencies.

That would also be incorrect for an arbitrary f right? f could map from e.g. Vec<http::header::HeaderName> to Option<String> --- the reference to http::header::HeaderName should not be preserved; if you do preserve it, and it's your only usage of a type from the http crate, you'll end up with a dependency on http that you don't need.

It's very unlikely that eliminating SymbolReferences upon usage of this function will cause us to stop depending on a crate that we do need. But if we do, the build will fail, which I think is a better outcome than silently depending on something we don't need.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python

A new doc preview is ready to view.