Make the name of the client property in config files more generic.

[dllh]

This lets us reuse the value in places besides its current use in Tracks without just using the Tracks-specific name, which would ultimately become confusing and inaccurate.

The use case that led me to propose this change is that we'd like to be able to send information to the REST API about the client software when fetching information about live chat, so that we can send back info that will route desktop user chats differently than web user chats. Rather than adding some kind of janky user agent or oauth app id check to the REST API, I'd like to send a parameter along with the request that will tell the API how to respond.

Since this client property already exists, I thought I'd rename it to genericize it rather than adding another property with the same value.

I tested by running loading some screens within the client and confirming that Tracks pings landed with the client event property intact.

Of course, now that I look back at blame for the config files to see who to ping for review, I see that @mjangda made pretty much the exact opposite commit in the pre-oss repo (renaming client to tracks_client_prop to be more explicit). Since we now have another use for this property, maybe it's time to be more general now. :)

[mjangda]

My only worry would be someone deciding to change the value without realizing how it's used and breaking all our Tracks events.

Plus, client_prop might be better named as client_slug?

[dllh]

We sure wouldn't want to break all our Tracks events. Do you think the worry there makes it worth adding a new config item that duplicates the values in the current property? Or should we trust people not to blindly change values without considering the ramifications?

I'm not married to client_prop, though client_slug to me implies that there's something like client_title or a similar value as well. I prefer your client_slug to client_prop but wonder if we shouldn't just go back to the original client instead. Or maybe client_do_not_change_value_lightly. ;)

[dllh]

I've updated to use client_slug instead of client_prop. I'm not too worried about anybody changing the value without realizing how it's used, though maybe I'm not being cautious enough (surely somebody would check for references before changing a name like this).

We could add a new config item if we really want to be safe, but it seems to me like overkill and redundant redundancy. @mjangda what do you think?

[dllh]

Chatted with @robfelty from the data team a bit about this in Slack, and he didn't seem too worried about the risk.

[blowery]

I think this is fine. Code looks good. Makes me wish even more for something like JSON+Comments or YAML for config files.

Might rebase this, as it has a pretty old base?

[blowery]

Code works. Assuming the rebase is clean, 🚢