Would it make sense to return true if `checkConnection()` is called on a master node?

[2bndy5]

As long as the master node's radio is idling in RX, I think this would be interpreted as "connected to the mesh." Otherwise, user code written for both master and child nodes might end up calling renewAddress() on master node if their code doesn't understand that it is running the master node. I see no considerations in renewAddress() (& its helper requestAddress()) when the node ID is set to 0.

Originally posted by @2bndy5 in #250 (comment)

[2bndy5]

I ended up implementing this in my CirPy port (nRF24/CircuitPython_nRF24L01@cb9b60b) because mesh nodes do not allow users to explicitly set the mesh_address (node_address in CirPy port) -- actually nothing is private in python, so users could monkey with internals (mesh_node._addr = 0), but this is generally discouraged. According to the mesh bonding paradigm, the mesh_address should be read-only in the public API since it is entirely dependent on the master node's management of address leases.

I also short-circuited renew_address() if called on a master node (nRF24/CircuitPython_nRF24L01@007e885). Bear in mind that the CirPy port uses inheritance to implement MESH_NOMASTER; the RF24Mesh class derives from RF24MeshNoMaster class.

[TMRh20]

This sounds good. It would be nice to be able to run nearly the same code on differently configured devices.

[2bndy5]

In that case, we should go through and check for any functions not defined for master nodes but are defined for (MESH_NOMASTER) non-master nodes.