[dv/rstmgr] Apply different reset kinds where applicable

[matutem]

Most unit tests use the default apply_reset kind argument. The rstmgr unit has both AON and non-AON domain components, so the apply_reset distinction is important. One way to exercise it could be to call apply_reset with a randomized kind argument between rounds of various tests.

estimate 8

[sriyerg]

Please see example: https://github.com/lowRISC/opentitan/blob/82278f92b83d280102116941dd1d6c19e6953bd8/hw/ip/rv_dm/dv/env/seq_lib/rv_dm_base_vseq.sv#L57

For rv_dm I defined 3 different reset strings with the same goal as yours - be able to apply different kinds of resets randomly and verify expected behavior.

[andreaskurth]

Triaged for pwrmgr. Assigning to M2.5 with https://github.com/lowRISC/opentitan/labels/Priority%3AP2 because this would increase coverage around resets, which IMO is relevant.

[GregAC]

Triaged for rstmgr, agree with @andreaskurth

[GregAC]

Estimate range: 4 - 8

[andreaskurth]

Triaged for clkmgr (sorry this somehow slipped my filters), agreed on https://github.com/lowRISC/opentitan/labels/Priority%3AP2

[msfschaffner]

Discussed with @matutem - this seems to be a coverage closure exercise that can be done after M2.5. We have many TLT's that already stress the interconnected reset behaviors of the *mgr's.

[matutem]

I undated the issue to state it only applies to rstmgr, not clk or pwrmgr.

[matutem]

In rstmgr_reset_vseq we apply random resets, which include hard (aon) and regular resets, so this issue can be declared complete.