Fix nessus scan listing to return scans

[bmagistro]

Description

Fixes listing of scan from nessus. Prior to this, the list returned would be 'scans', 'folders', 'timestamps'. With the change the scan list returns a list of scans (and can be filtered by folder).

Type of change

Please delete options that are not relevant.

• [ X ] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Tested locally with our Nessus 10.9.2 instance.

[SteveMcGrath]

To note, this would end up breaking any existing code leveraging this endpoint, is there any reason to drop the folders and timestamps keys?

[bmagistro]

This may have been a misunderstanding of how the api is intended to work on my part then.

Calling the function list in the ScansAPI ( https://github.com/tenable/pyTenable/blob/main/tenable/nessus/scans.py#L331-L353 ) I would expect a list of scan objects, not the three keys returned. If accessing folders that appears to be an equivalent of the folders list api (https://github.com/tenable/pyTenable/blob/main/tenable/nessus/folders.py#L63). I didn't dig into which timestamp is returned, but would be willing to venture a guess its probably the timestamp of the last scan run. Again this doesn't seem at all related to returning a list of scans.

---

full disclosure, we hit a couple other bumps similar + related to those in #757 while trying to build out some internal tooling and are pausing this while we re-evaluate our next steps.

[SteveMcGrath]

My understanding is that the folders returned are the folder objects related to the scans returned. The timestamp I honestly don't know what it refers to, and there isn't any documentation in the API docs that point to what it is.

Overall I'm not opposed to the change, but with the potentially backwards compatibility breaking change here, I wonder if the right move is to update the docstring to instead confer the correct action based on what the API is returning instead of masking part of the response.