Resuming from checkpoint, mid epoch gives a very distorted time estimate

Nobody has claimed this yet.

### Bug description

This might be related to : https://github.com/Lightning-AI/lightning/issues/13124

Currently when resuming from a deepspeed checkpoint, it seems like the time estimate, uses the "current running time" against the "total dataset steps". This gives incredibly warped numbers, when resuming mid epoch for long 1 day+ runs.

Where you can see estimates for runs which would have taken hours, being in minutes.

This can be observed even in small dataset / models, where you can see crazy it/s rates - and remaining time estimate - at the start, which improves over time, but never fall back inline with a more realistic estimate (especially if it resumed > 50% mark)

I do not have full repro steps here, but i am filing it so that others might be able to confirm / follow up on it.

### What version are you seeing the problem on?

v2.0

### How to reproduce the bug

_No response_

### Error messages and logs

_No response_

### Environment

Current environment

```
#- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow):
#- PyTorch Lightning Version (e.g., 1.5.0):
#- Lightning App Version (e.g., 0.5.2):
#- PyTorch Version (e.g., 2.0):
#- Python version (e.g., 3.9):
#- OS (e.g., Linux):
#- CUDA/cuDNN version:
#- GPU models and configuration:
#- How you installed Lightning(`conda`, `pip`, source):
#- Running environment of LightningApp (e.g. local, cloud):
```

### More info

_No response_

cc @tchaton @awaelchli

Start by reproducing a run resumed from a DeepSpeed checkpoint in the middle of an epoch, comparing the reported time estimate with a fresh run on a small dataset. Done means the elapsed-rate and remaining-time estimates remain realistic after resuming, including when more than half the epoch has already completed.

Written by the indexing model from the issue text.