Useless data saved in salesforce_mapping entities

To make this viable for review, please make sure it doesn't change existing behavior.
ie. what is useless to you may be in use by someone else.
You can't just throw out a huge chunk of data, since we have a stable release and many installs which might break.

Next, please change the variables named like "useful_sf_properties" to something more descriptive.

Right, so I think by default the entire, mostly useless mapping should be stored - same as the current behavior.
Your patch should allow it to be overridden by some means.

For example, make the variable_get() return FALSE by default, and only apply the array intersection if the default has been overridden.

'salesforce_mapping_stored_sf_properties' seems more appropriate

Finally, I would suggest that you should apply some bare-minimum to any default, so that overrides do not break mappings altogether.
In other words, make sure that at least "name" is saved for all sf field properties.

This makes more sense to me.

In case this is related: when put into a feature that is enabled on multiple sites, the 'created' date attribute of the mapping is stored in the feature, and ends up showing as an overridden value, putting the feature into an overridden state that cannot be fixed without hand-editing the feature.

However that date is different on every environment. Therefore that value should be removed from the exported attributes.

I've updated with a different approach. This adds a hook that allows anyone to restrict the list of properties if they desire, and otherwise leaves everything as normal.

Should probably include properties the module uses by default. This could use some work: repetition of the force inclusions is sloppy, probably should do a true/false return on the hook about whether to override and just implement the hook without a return value from within the SF modules to dictate which properties they want to assert.

7.x is no longer supported