This is new in v4 since we now auto detect which sessions to optimize and which to leave alone. If the TCP session is seen on both appliances, then it is eligible to be optimized. If a session is only seen on one appliance but not the other, then it is bypassed. Hence, MultiSite has been removed and configuring Traffic Policies are now optional. This is a big step forward considering that these are often miss-configured in v3.
Wanos has the same TCP reset capability as Silver Peak and Riverbed Steelhead:
Configure -> Reset -> Reset TCP-X
If TCP-X is not enabled: Enable TCP-X, then disable TCP-X again
As like the other vendors, this is only expected to be used in a lab/test environment. Under normal production environments it would not be normal to reset TCP sessions in order to force a TCP reconnect to start optimization for a particular application like CIFS/SMB.
As for the ping idea, it is not really workable. The remote peer could be removed from the inline position but still respond to ICMP and even wanos control traffic like PLR and RTT measurements may still flow between the sites. This would cause the peers to remain "Active" causing the device that is inline to keep optimization alive. This would cause a blackout for optimized traffic. Better to be safe and only optimize while valid traffic is seen. When one of the peers are removed or moved where traffic flow is not correct, the peers should go into Idle state to avoid traffic blackout.
Test in a production network. If you still see peers Idle occasionally but want to force them to "Active" increase the peer timeout value under settings.