While debugging NETCONF-702, I realized there is no unit test coverage for these cases.
The fix for NETCONF-696 created a regression caught in CSIT, which is how we ended
up with NETCONF-702

We need four test cases to pass. two already exist, but one is now failing (the regression)
passing case
newly failing case (but used to pass)

Essentially, it's doing the same thing, which is hitting this URI twice:

/rests/data/network-topology:network-topology/topology=topology-netconf/node={{node}}/yang-ext:mount/example-action:interfaces/interface=eth1/reset

The first (passing case) is using an XML request and body:

<?xml version="1.0" encoding="UTF-8"?>
<input xmlns="https://example.com/ns/example-action">
    <delay>600</delay>
</input>

and the failing case is JSON:

{
    "example-action:input": {
        "delay": 600
    }
}

The URI it's triggering is triggering an RPC action which is defined in one of the
schemas that is used to mount the netconf testtool. The schemas are in the
int/test repo, here

The original bug that produced the fix that created this regression was related to
calling an RPC on an action from a yang augmentation which is defined a little
differently in the yang files. To recreate this scenario, there are two yang files
attached to NETCONF-696
augment-main-a@2014-01-21.yang
main@2014-01-21.yang

if those files are added to the int/test repo schemas/ folder then the same suite with
the already existing test cases will have the ability for the next two test cases needed.
They are identical to the already existing cases, but they will use a different URI that
points to the new RPC action from the augmention. This one:

rests/data/network-topology:network-topology/topology=topology-netconf/node={{node}}/yang-ext:mount/main:cont/cont1/reset