Decoding of Slice1 tagged proxy that holds null broken in 0.3

[bernardnormier]

In IceRPC 0.3.0 (but no 0.2.x, 0.1.x), the decoding of a Slice1-encoded tagged proxy that holds the null value (a very uncommon situation) is broken.

The issue is that in 0.3.0, we decode Slice1-encoded tagged proxies/service addresses with DecodeServiceAddress--the non-nullable extension method--when we should be using DecodeNullableServiceAddress like in previous versions.

I propose to fix this bug as follows:

• in 0.3.x, change slicec-cs to encode custom tagged types with the non-nullable EncodeXxx extension (like we do already) but change the decoding of custom tagged types to use the nullable DecodeNullableXxx extension

That's what we did in previous versions. It works well but is a bit inconsistent, since we're using EncodeXxx for encoding and DecodeNullableXxx for decoding.

• in 0.4.x, change slicec-cs and the SliceEncodeExtensions to use EncodeNullableXxx / DecodeNullableXxx for tagged custom types. That's just for consistency. For tagged fields/params, we always pass a non-null value to EncodeNullableXxx.

And the reason we're not simply doing the 0.4.x fix on 0.3.x is because changing the EncodeTagged extension on 0.3.x would most likely break binary compatibility.

It's also possible we can find a single binary-compatible fix that works for both branches.

Also, to be clear:

• in IceRPC, we never distinguish between "not set" and "set holding a null value". In particular, we never Slice1-encode a tagged service address that is "set to null". We would encode "not set" in this situation.
• with Ice 3.7 and earlier, it is possible (but probably very rare) to encode a tagged proxy set to the null value
• for Ice 3.8, we plan to sync-up with IceRPC and remove "encode set with a null value" - nevertheless, the decoding should still work for backwards compatibility

[InsertCreativityHere]

Fixed by #3929!

---

It works well but is a bit inconsistent, since we're using EncodeXxx for encoding and DecodeNullableXxx for decoding.

This inconsistency has real consequences if there's a difference in encoding between nullable and non-nullable versions of your type (which should nearly always be true). If EncodeFoo sends a [string], but DecodeNullableFoo expects a [bool][string] the decoding will fail (the bool encodes whether it's set or not).

This bug is why I opened #3919: we really do need to be using the same function on both sides (encoding/decoding).

3919 just happened to pick the wrong function, because I forgot about this capability of Ice, and only considered the IceRPC docs.