High Critical Time reported when a deferred message arrives.

### Symptoms

When a timeout message with a header like the example below arrives a very high value is reported by the `Critical Time` performance counter. Such a high value is due to the fact that the `NServiceBus.TimeSent` header is set when sending the message to the timeout store and not reset when timeout store delivers it to the destination. This could cause false alarms for administrators if they are monitoring Critical time.

### Who's affected

User's who use the defer feature (which means anybody who uses timeout feature of sagas) and has configured automated alarms based on the `Critical Time` performance counter.

### Details

An example of such message would have headers like this:

	 <HeaderInfo>
	  <Key>NServiceBus.Version</Key>
	  <Value>3.3.5</Value>
	 </HeaderInfo>
	 <HeaderInfo>
	  <Key>NServiceBus.TimeSent</Key>
	  <Value>2013-06-13 07:37:04:712995 Z</Value>
	 </HeaderInfo>
	 <HeaderInfo>
	 <HeaderInfo>
	  <Key>NServiceBus.Timeout.Expire</Key>
	  <Value>2013-06-19 23:00:10:000000 Z</Value>
	 </HeaderInfo>
It was failing i.e. the tests were failing but I assumed the the comment about powershell is true and it should remain explicit. Need to reevaluate.