ev3dev: cache invariant values for motors

[kortschak]

See ##50 (comment).

• address not handled at the motor level - AddressOf provides this
• commands
• count_per_rot
• count_per_m
• full_travel_count
• driver_name
• max_speed
• stop_actions

[kortschak]

@dlech A question about behaviour of commands and stop_actions. Are we always guaranteed that reads to these attributes will return something even if it's zero-length?

[dlech]

These will never be zero length. (But even if they were, you would still probably get a newline.)

[kortschak]

I'm not sure what I was thinking when I wrote some of the test code, but that is fixed now.

[kortschak]

@dlech Are you happy with the state of the solution to this #54 and #55?

[dlech]

If it was up to me, I would also cache the mode-specific values of sensors when you set the mode.

[kortschak]

I can understand the motivation behind this, but I am concerned about values going stale in normal operation. I am probably being overly cautious here. The current situation does not prevent users from having more than one handle per device, which means that different goroutines may have different ideas about what is happening with the underlying device if the value is cached. An approach to deal with that is to prohibit having more than one handle per physical socket. This complicates the device opening code, but is achievable with a global mutex-protected map of port identifiers to ev3dev.Device that is checked on open. The simpler option is to just tell people not to.

[kortschak]

Another alternative is to have a global mutex-protected map to a struct that holds the cached values and the device identifier - if the device ID does not match a querying device then the value is invalid. This feels more brittle to me though, and does not get rid of the error return, which is a motivation for these changes.