BUG: na_ontap_vserver_peer falsely returns when peering multiple clusters with the same vserver name

[crisp island]

If you have a scenario where you have 3 or more clusters with the same vserver name, this module cannot peer any more than the first cluster.

Source1: cluster1
Vserver Name: fsx

Source2: cluster2
Vserver Name: fsx

Dest1: cluster3
Vserver Name: fsx

I wish to peer cluster1 and cluster2 to cluster 3. Two source clusters, one destination. In my environment, there could be 20 source clusters and 1 destination.

Looping through, we would first cluster peer these. The cluster peer process is successful as each cluster is uniquely named and the UUID is used by the cluster peer process. Result =

Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
FsxId0b9c77877f09dc7b9 (cluster1)   1-80-000011           Available      ok
FsxId0c239b3a9e77ffaaf (cluster2)  1-80-000011           Available      ok```

Next, we want to vserver peer both source SVMs to the destination. We do so using the following ansible code: 
```  - name: Create vserver peer from {{ source_cluster }} to {{ destination_cluster }}
    netapp.ontap.na_ontap_vserver_peer:
      state: present
      hostname: "{{ netapp_hostname }}"
      username: "{{ netapp_username }}"
      password: "{{ netapp_password }}"
      vserver: "{{ vserver_name }}"
      validate_certs: no
      https: true
      use_rest: always 
      peer_cluster: "{{ destination_cluster_name }}"
      peer_vserver: "{{ destination_vserver_name }}"
      local_name_for_peer: "{{ destination_cluster }}"
      local_name_for_source: "{{ source_cluster }}"
      applications: 
        - 'snapmirror'
      peer_options:
        hostname: "{{ netapp_destination_hostname }}"
        username: "{{ netapp_destination_username }}"
        password: "{{ netapp_destination_password }}"
        validate_certs: no
        https: true
        use_rest: always```

CONTINUED AS COMMENT

If this is executed, the following will happen:

1. The first vserver peer will succeed. The module will handle the local-name field and the peer will complete as expected
2. Any subsequent peer will fail with the following error message (the first time the playbook is run)

  msg: 'Error fetching vserver peer fsx: calling: svm/peers: unexpected response {''records'': [{''uuid'': ''d940339d-5df5-11ee-ae20-af258d6d7a53'', ''name'': ''cluster1'', ''svm'': {''name'': ''fsx''}, ''peer'': {''svm'': {''name'': ''fsx''}}, ''state'': ''peered'', ''_links'': {''self'': {''href'': ''/api/svm/peers/d940339d-5df5-11ee-ae20-af258d6d7a53''}}}, {''uuid'': ''e77aec39-5df5-11ee-9ce8-39fd095c6598'', ''name'': ''fsx.1'', ''svm'': {''name'': ''fsx''}, ''peer'': {''svm'': {''name'': ''fsx''}}, ''state'': ''pending'', ''_links'': {''self'': {''href'': ''/api/svm/peers/e77aec39-5df5-11ee-9ce8-39fd095c6598''}}}], ''num_records'': 2, ''_links'': {''self'': {''href'': ''/api/svm/peers?svm.name=fsx&peer.svm.name=fsx&fields=name%2Csvm.name%2Cpeer.svm.name%2Cstate%2Cuuid''}}}. for query: {''svm.name'': ''fsx'', ''peer.svm.name'': ''fsx'', ''fields'': ''name,svm.name,peer.svm.name,state,uuid''}'

3. If the playbook is rerun, it will respond as OK (which is false)

The clusters are left in the following state:

cluster1: ```FsxId0b9c77877f09dc7b9::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver

---

fsx cluster3
peered FsxId01ff064f3774458b1
snapmirror fsxcluster2:FsxId0c239b3a9e77ffaaf::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver

---

fsx cluster3
initiated FsxId01ff064f3774458b1
snapmirror fsxcluster3:FsxId01ff064f3774458b1::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver

---

fsx cluster1
peered FsxId0b9c77877f09dc7b9
snapmirror fsx
fsx fsx.1 pending FsxId0c239b3a9e77ffaaf
snapmirror fsx```

If you rerun the playbook directed ONLY at cluster2, the module still responds as OK, even though it is not peered. It seems to just look up the relationship of ANY relationship that has a source vserver name matching the one we are trying to peer, and returns that it's fine

The vserver peer accept process is documented by Netapp here: https://docs.netapp.com/us-en/ontap-cli-9111/vserver-peer-accept.html

In the last paragraph, the documentation describes this exact scenario:
During execution of vserver peer create command on peer cluster, peer Vserver name is locally refered by unique system generated name

The example below shows this exactly as I have described. ONTAP appends a .1 to the peer-vserver name.

If I continue this, and try to peer 10 clusters to 1, all with the same vserver name, ONTAP will keep appending numbers to the end of the vserver peer relationship

[crisp island]

WORKAROUND - if you are impacted by this, you can do the following (messy) workaround. Still via API, so at least has that benefit

1. Write a new Ansible task to run the "vserver/peer/accept" command via na_ontap_rest_cli. Example:

    na_ontap_rest_cli:
      hostname: "{{ netapp_destination_hostname }}"
      username: "{{ netapp_destination_username }}"
      password: "{{ netapp_destination_password }}"
      validate_certs: no
      https: true
      command: vserver/peer/accept
      body: {vserver: "{{ destination_vserver_name }}", peer-vserver: "{{vserver_name}}.1", local-name: "{{ source_cluster }}"}
      verb: 'POST'
    ignore_errors: true```

You will need to `ignore_errors` on your `na_ontap_vserver_peer` task, as this will fail the first time your 2nd peer request takes place. You will have to loop or repeat this as many times as needed, changing the `"{{vserver_name}}.1"` to .2, .3 etc.
This task will also need `ignore_errors` as it will fail every subsequent time it is executed (after the first successful time)