Remove all old timing calls

[ravi-mosaicml]

1. Remove all uses of state.max_epochs; replaced with state.max_duration -- specifically in stochastic depth (Remove old timing calls from stochastic depth #229) and sequential length warmup (Remove old timing calls from Sequential Length Warmup #226). However, it does not fix the latter, as we still need to update the algorithm to support max_duration in terms of tokens or samples.
2. Replaced all state.step with int(state.timer.batch)
3. Replaced all state.epoch with int(state.timer.epoch)
4. Replaced all state.batch_idx with int(state.timer.batch_in_epoch)
5. Removed the constraints that max_duration be specified in epochs; it can now be in any unit. Added test cases for specify max duration in batches.
6. Added a helper method to the Time class to convert it to a timestring (with a test case)

Closes #146
Closes #229
Closes #512

[hanlint]

Hmm would it make sense to attach to state the epoch, etc. properties? That would reduce the code verbosity here and also be easier for developers to access directly.

[ajaysaini725]

Overall looks great just a few comments

[ravi-mosaicml]

Hmm would it make sense to attach to state the epoch, etc. properties? That would reduce the code verbosity here and also be easier for developers to access directly.

Unfortunately, this would lead to naming conflicts, since batch is already defined on state. If we bound it directly on the state, then we would need to use a different name on the state object -- e.g. batch_idx, sample_idx. I think this could lead to confusion if it's called state.epoch_idx on the state and timer.epoch on the timer (it also wouldn't be that much less verbose -- saves two characters now!)

I could rename it in both places, but am not a huge fan of having everything in the timer be _idx'ed.

Alternatively, we could rename batch to batch_data? Also not a huge fan of that.

Agree it would be nice if these properties were more visible, but a good solution doesn't come to mind. Thoughts?

[ravi-mosaicml]

Random thought - should we have a doctest here to test for from composer import ____ imports that we expect to work (that way if someone changes something within a module like callbacks that somehow breaks importing directly from Composer we catch it here)

Any import from a submodule will attempt to load the parent module's __init__.py, so our tests already check to ensure that the parent's __init__.py is bug-free. As for ensuring that, say, composer.callbacks doesn't have a bug in it, we should use the highest-level import whenever possible (e.g. from composer import Trainer, not from composer.trainer.trainer import Trainer) in the tests. But going to leave that out of this PR as that would be a larger change.

[hanlint]

Good point on the naming conflicts -- let's keep them in state.timer for now then.

[hanlint]

For the method cards, the actual READMEs should sit in the composer/algorithms/ folder, with a symlink in the docs/source.

[ravi-mosaicml]

For the method cards, the actual READMEs should sit in the composer/algorithms/ folder, with a symlink in the docs/source.

Whoops, good catch. Just fixed this.