String types in mock driver / unit tests.

[bewing]

I noticed today when comparing output from a real call to the EOSDriver for a new method I was writing to output from the mock driver in napalm base, that the data returned by the mock driver may not be type unicode, when the data returned by the real driver is.

It has been posited in slack that this may be due to how the strings are read from disk by the mock driver, versus returned from other underlying libraries in the real drivers.

May wish to investigate changing how we read data for test cases in order to more accurately write unit tests, and avoid additional calls to py23_compat.text_type.

Test case and additional discussion needed.

[dbarrosop]

I remember you already posted a suggested solution on slack, is this something you can PR?