Transaction timeouts use memory after transaction is destroyed

[ajbeamon]

Transaction timeouts create delay tasks for the run loop that persist for the entire duration of the timeout, regardless of whether the transaction that created them has been destroyed. This could potentially be a concern in cases where the timeout is set to be very long.

I haven't done a full accounting of the memory, though I think that there are 128 bytes used in 64-byte fast allocated chunks plus some other memory that's not being fast allocated.

[etschannen]

Use repeated small delays so that the timeouts will be cleaned up faster after being cancelled.

Audit long delays used generally in the core to determine if this is an issue anywhere else.