Decode of nil data (#8179)

## What changed?

Don't catch `Data: nil` in test; let it fall through to decoder. The
decoder will return an error. An error is the better choice than a `nil`
response since that signals to the user that the decoded data is
usable/valid.

## Why?

Follow-up to #8111; an
internal test expects an error instead of `nil`.

## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)

## Potential risks

Hard to believe that returning nil and using un-decoded data is a
good/valid alternative.

Author: stephanos

common/persistence/serialization/codec.go

@@ -49,9 +49,6 @@ func Decode(data *commonpb.DataBlob, result proto.Message) error {
 	if data == nil {
 		return NewDeserializationError(enumspb.ENCODING_TYPE_UNSPECIFIED, errors.New("cannot decode nil"))
 	}
-	if data.Data == nil {
-		return nil
-	}
 
 	switch data.EncodingType {
 	case enumspb.ENCODING_TYPE_JSON:

common/persistence/serialization/codec_test.go

@@ -42,6 +42,16 @@ func TestProtoDecode(t *testing.T) {
 		assert.Contains(t, err.Error(), "cannot decode nil")
 	})
 
+	t.Run("empty data blob", func(t *testing.T) {
+		blob := &commonpb.DataBlob{}
+
+		var result persistencespb.ShardInfo
+		err := Decode(blob, &result)
+		require.Error(t, err)
+		assert.IsType(t, &UnknownEncodingTypeError{}, err)
+		assert.Contains(t, err.Error(), "unknown or unsupported encoding type Unspecified")
+	})
+
 	t.Run("nil data field", func(t *testing.T) {
 		blob := &commonpb.DataBlob{
 			Data:         nil,