Performance regression in decoding struct type

[chenyan-dfinity]

With the new decoding code, there is a const factor overhead in decoding struct type, likely due to Type clone.

Benchmark for 5a76023

Click to view benchmark

Test	PR Benchmark	Master Benchmark	%
Blob/&str	263.3±59.50µs	268.1±66.71µs	-1.79%
Blob/ByteBuf	225.1±65.30µs	229.4±67.28µs	-1.87%
Blob/Bytes	129.3±27.79µs	125.3±28.09µs	+3.19%
Blob/String	302.5±65.60µs	303.0±67.89µs	-0.17%
Collections/vec (text, nat)	94.4±2.55ms	94.2±1.80ms	+0.21%
Collections/vec int	44.6±0.06ms	41.9±0.07ms	+6.44%
Collections/vec int64	32.7±0.08ms	26.2±0.09ms	+24.81%
Collections/vec nat8	24.4±0.04ms	19.1±0.03ms	+27.75%
option list/1024	3.2±0.01ms	1185.5±2.33µs	+169.93%
profiles/1024	5.6±0.02ms	2.7±0.01ms	+107.41%
variant list/1024	3.0±0.01ms	1354.9±2.70µs	+121.42%

Originally posted by @github-actions[bot] in #211 (comment)

[matthewhammer]

FWIW, I have a usecase that creates "large" trees (each under 500k bytes) and I notice a 10x difference between 0.6 and 0.7 (where 0.6 is 10x faster than 0.7).

Faster decoding (via 0.6):

Slower decoding (via 0.7):

[chenyan-dfinity]

Fixed in #405