[TASK] Handle unsanitary NetBox response parameters

[ByteOtter]

After further investigation, the erroneously null fields in NetBox's responses to the Interface endpoints definitely looks like this is a problem on NetBox's end.

Looking at the fields link_peers_type and connected_endpoints in the Interface struct, we can see that the schema requires them to be a String and a Vec. Which gets translated correctly in thanix_client.
However, the application returns both of these values as null, which does not correspond with the schema.

This leads to several conclusions:

1. This could a problem that can re-occur in more fields than the ones we encountered here.
2. A temporary workaround is required to allow v0.1.0 to be working with NetBox v3.6.x as per the decision made in [EPIC] Port API calls to NetBox v4.x #74.
3. An automated integration test suite is required to catch these errors correctly.

Backend bug hunting must also be conducted as we cannot be sure this problem is fixed with NetBox v4.x.
I had opened an issue with NetBox about a possible bug on this end (netbox-community/netbox#16301) they asserted that this is not an issue with them. We need to collect further information before we can proceed to report a bug again.

Originally posted by @ByteOtter in #73 (comment)

[ByteOtter]

This has been addressed somewhat by implementing a workaround when generating API clients with Thanix. See The-Nazara-Project/Thanix@7c54106 for more info.

The issue will stay open for now to remind us to address this again in the future.

Also, further research needs to be done on NetBox's end whether this may be an issue with their database migration problem.