[Fix] Fix ProfileHook cannot profile ddp-training

[HAOCHENYE]

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.

Motivation

PyTorch profiler support profiling distributed program, however, the current implementation of ProfilerHook's method is decorated by master_only, which limits profiler capability.

Besides, If the scheduler is configured for the ProfilerHook, an error will be raised like this:

RuntimeError: stack.size() INTERNAL ASSERT FAILED at "../torch/csrc/autograd/profiler_python.cpp":963, please report a bug to PyTorch. Python replay stack is empty.

The main reason is that self.profile.step will not be called if scheduler is not None:

mmengine/mmengine/hooks/profiler_hook.py

Lines 226 to 236 in 8a0fae0

	self.profiler.step()
	if not self.by_epoch and runner.iter == self.profile_times - 1:
	self._export_chrome_trace(runner)
	def _export_chrome_trace(self, runner):
	"""Exporting content."""
	runner.logger.info('profiler may take a few minutes...')
	self.profiler.__exit__(None, None, None)
	if self.json_trace_path is not None:
	self.profiler.export_chrome_trace(self.json_trace_path)

which is not consistent with the official tutorial

Modification

Please briefly describe what modification is made in this PR.

BC-breaking (Optional)

Does the modification introduce changes that break the backward-compatibility of the downstream repos?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.

Use cases (Optional)

If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.

Checklist

1. Pre-commit or other linting tools are used to fix the potential lint issues.
2. The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
3. If the modification has potential influence on downstream projects, this PR should be tested with downstream projects, like MMDet or MMCls.
4. The documentation has been modified accordingly, like docstring or example tutorials.