Zipkin Receiver: Zero Duration Spans have no endtime

[chris-smith-zocdoc]

Describe the bug
If a zipkin span is sent with a zero duration or without the duration set, the zipkin receiver does not set the end time on the span. This bug was introduced in #1446

With the endtime unset, this causes errors in other processors that may look at the span duration as they may do end - start to compute the duration, resulting in a large negative duration.

Steps to reproduce
Post a span to the collector like this

[
{
        "traceId": "98bea8e9894443d9",
        "id": "98bea8e9894443d9",
        "kind": "SERVER",
        "name": "fast-span",
        "timestamp": 1599577303251000,
        "localEndpoint": {
            "serviceName": "client-name",
            "ipv4": "127.0.0.1"
        },
        "tags": {
            "foo": "bar"
        }
    }
]

or like this

[
{
        "traceId": "98bea8e9894443d9",
        "id": "98bea8e9894443d9",
        "kind": "SERVER",
        "name": "fast-span",
        "timestamp": 1599577303251000,
        "duration": 0,
        "localEndpoint": {
            "serviceName": "client-name",
            "ipv4": "127.0.0.1"
        },
        "tags": {
            "foo": "bar"
        }
    }
]

What did you expect to see?
The endtime should be set to the starttime

What did you see instead?
endtime is the default value 0

What version did you use?
Version: 8e5c6065eb0e07e9f4d01552de22acccf174a41a

Additional context
I believe the fix should be to return to the previous implementation

https://github.com/open-telemetry/opentelemetry-collector/blob/master/translator/trace/zipkin/zipkinv2_to_traces.go#L169-L171

dest.SetStartTime(pdata.TimestampUnixNano(startNano))
dest.SetEndTime(pdata.TimestampUnixNano(startNano + zspan.Duration.Nanoseconds()))