der: Tracking issue for deoptimiztions since `v0.7`

[dishmaker]

Due to BER:

• using ber features makes DER reader slow (about 20% slower)
• read_nested now includes primitive DecodeValues too
  (added in der: add Reader::read_value, auto-nest DecodeValue #1877)
  (partial fix in der: auto read_nested in trait: DecodeValue::decode_value_nested #1916)
• indefinite flag in Length
  (der: add indefinite flag to Length #1894)
• users of pure DER need to compile BER code too (maybe add feature flag?)
  (added in der: constructed OctetString support #1899)
• constructed flag in Header
  (will be added in Negative test case for constructed, definite-length octet string #1931)

[tarcieri]

Without data to show these are "deoptimizations" this is just a list of things that changed

[dishmaker]

28% slower SubjectPublicKeyInfoRef due to indefinite flag in Length

Commit b288a61 (after) vs parent cce5ea4 (before)

Generated using cargo bench -p spki -F alloc #1947

	before [ns/iter]	after [ns/iter]
	211,24	336,07
	213,34	276,61
	226,8	274,62
	211,25	275,06
	218,52	278,1
	214,29	268,06
	206,68	274,78
	224,29	280,75
git rebase again
	216,02	263,63
	215,31	272,16
	223,22	274,06
	225,18	265,37
	217,86	278,39
	208,51	278,83
	202,52	265,6
average:	215,67	277,47

[dishmaker]

Current master 7674d0c is also 24% slower than cce5ea4

[tarcieri]

The latest master is what to compare to. I imagine Tag::peek_is_constructed, which was removed, was not particularly fast, whereas the current implementation which recovers the constructed bit at the time the tag is decoded should've taken care of at least that much.

That said I'm a little surprised the current master is that much slower. A feature flag might be interesting to see if it can recover all of the performance.

[dishmaker]

Here is a comparison of #1726

500cd65 vs parent 0b3a0b2

Looks like indefinite u32::MAX would be about 1% slower (similar to Length::MAX)

	After / no limit [ns/iter]	Before / with limit [ns/iter]
	219,64	221,78
	217,45	223,65
	215,18	226,07
	219,46	223,19
	217,39	216,55
git rebase again
	219,15	216,43
	216,06	220,75
	219,33	215,86
	216,37	214,27
	216,26	215,14
	214,06	224,7
	221,29	224,1
	218	220,31
	220,99	221,03
git rebase again
	220,21	214,04
	219,93	218,8
	221,31	223,28
	216,87	227,41
	218,95	222,66
	209,68	218,36
	219,15	222,18
average:	217,94	220,50

[tarcieri]

I think these can all either be considered addressed or "won't fix"