In #390 one of the expectations failed unexpectedly while testing request-level configuration.
It fails, because the duration that gets merged is a two-field message: it would make here to see
both the number of seconds and nanoseconds to be overridden.
However, the seconds part is set to '0', which equates to the default of the underlying int
type, and the fact that we are using proto3, which doesn't merge default values.

For merging purposes, we it would be more intuitive for to treat durations as an atomic field:
if either seconds or nanoseconds is provided, both fields should be affected in the merge result.
An override specified in json looks like "0.01s" after all, and it doesn't make sense for the merge to treat
the whole number and the fraction as separate components to consider for merge.