Add disconnect_mac_address Function

[ddriddle]

Closes #28

[edthedev]

Testing on this is blocked by permissions. Networking is looking into it for us.

[zdc217]

Networking got us partially unblocked. We can now send a disconnect request successfully but it ultimately fails on the Clearpass side because they need to set up a COA for the test devices. Uros and Chuck will look into that and get back to us. However, we do get a 200 OK response with information in the response that indicates that failure. I think there's enough in there to let us do the last bit of coding on our end.

We pushed a change that added async=false to the query string. We found apparently newer documentation that indicated it was required. The documentation available to us before said it was optional. See https://developer.arubanetworks.com/cppm/v6.11.0/reference/sessionactiondisconnectmacbymac_addresspost

TODO:

We'll need to adapt the disconnect_mac_address function in client.py to parse the response. The endpoint doesn't work as we were previously informed. It sends a 200 OK with the following response:

'{"action_id":"async_action_1770069218172","status":"complete","count":1,"count_success":0,"count_failed":1,"count_queue":0,"_links":{"self":{"href":"https:\\/\\/CLEARPASSURLHERE\\/api\\/session-action\\/disconnect%2Fmac%2FMACADDRESS"}}}'

We'll need to parse out the count, success, and fails in order to output something useful to the CSOC.

[edthedev]

We added the test per our discussion.

We can't re-record the cassette at this moment as our favorite test subject is offline.
It should reconnect later, and we can record the cassette we want.

[edthedev]

We stopped today without fixing the lint errors.

We also have not seen our favorite test target back online. (We must have disconnected it pretty hard...)

[edthedev]

We still want to update the return values from the disonnect_mac_address method, to translate the result codes - and indicate to the caller whether anything was online to be disconnected.

[edthedev]

Looks like we may be missing something, as that device appear online from networking's perspective.

Might be mis-matching the format for the mac in the API call?