The current log lifecycle metrics recognise 4 stages:

Generate - Send - Commit - Materialize

but "send" is a bit subtle. Up to the first send is PALI-dominated queuing, but between the first send and the last send we are retrying on account of log service interruptions which isn't really pali controlled.

The way the current code works "re-send" has different effects for oplog vs phylog:

• for oplog, entirely new entries are generated for re-send, so even the current code does not capture re-send-induced latency because a new start time is generated each re-send
• For phylog, the entry is the same but the re-send resets the send time, which has the effect of making generatedToSent look worse and sendToCommitted look artificially good.

To solve this problem we should track a phase between the first send attempt and the most-recent-successful-send before commit.