Ohana should vend immutable models

[adam-zethraeus]

For discussion:
The OHContact has mutable fields. Whilst customProperties and tags should perhaps stay mutable for the attachment of display metadata, the rest of the fields should probably be immutable when vended by the framework

[NickEntin]

I agree there are definite advantages to OHContact having immutable fields, but there are some problems associated with this. Of course, the data providers, post processors, and selection filters need to modify OHContact models, so we would presumably need to create an OHMutableContact model and use that when passing through components. Then when you access dataSource.contacts we would return immutable copies, but that creates a problem when you try to compare contacts and selectedContacts when you keep making copies. Additionally, apps may want to modify the contacts, and then save them (via the CN identifier, persisted contacts, etc.). We could make a mutable copy method for this, but then the contacts in the data source can't be updated, so you would have to reload everything. Overall, I think the disadvantages outweigh the advantages. Are there any specific advantages that you think make it worth it?

[maxwellE]

Solved in #42

[adam-zethraeus]

This is orthogonal to any particular copy bug.

A decent brief outline: https://engineering.linkedin.com/blog/2016/04/keeping-immutable-models-consistent