[FEATURE ds-boolean-transform-allow-null] allow null for boolean

[pangratz]

NOTE: this description is not completely accurate anymore, since the implementation changed so the allowNull flag needs to be passed to the options for the attribute. See discussion below for further context.

---

This feature allows null / undefined values for DS.attr('boolean')
attributes. Currently DS.BooleanTransform converts those values to
false; which means that a DS.attr('boolean') cannot be set to null
from the server. Other transforms (string, number) do allow null
values, so this is an inconsistency between the transforms.

The new feature ds-boolean-transform-allow-null changes this behavior
so null / undefined are converted to null. Since this is a semver
breaking change, a corresponding deprecation warning should be added
before this is accepted in ember data.

Current behavior of DS.attr('boolean'):

incoming	DS	serialized
null	false	false
undefined	false	false

Behavior of DS.attr('boolean'), having
ds-boolean-transform-allow-null feature enabled:

incoming	DS	serialized
null	null	null
undefined	null	null

---

Note that this feature only works if ds-transform-pass-options is
enabled as well, since passing the options from DS.attr to the
transform is added with that feature.

---

This addresses #3785.

---

TODO

• wait for implementation of RFC: Pass through attribute meta data to related Transform rfcs#1 so this PR can be updated with allowNull flag

[fivetanley]

@pangratz During the team discussion someone suggested passing an options hash to DS.attr({allowNull: true}) so we could maintain backwards compatibility. What do you think about this change?

[pangratz]

Seems good to me. But for this to work emberjs/rfcs#1 (also see discussion in #3111) needs to be go'ed and implemented, since currently the hash is not passed to transformations.

Would the eventual default in 3.x be that null are allowed for DS.attr('boolean'), so it is consistent with number, string and date transforms?

[pangratz]

Alright, emberjs/rfcs#1 has been accepted. Once that RFC is implemented I will update this PR so the allowNull flag is considered.

[pangratz]

Alrighty, I rebased onto latest master and now null is returned for null/undefined if the allowNull flag is set to true:

export default Model.extend({
  leBool: attr('boolean', { allowNull: true })
});

[bmac]

Should this be checking the 2nd argument for { allowNull: true }?

[pangratz]

@bmac I somehow forgot to commit the changes considering the allowNull flag 🤦 sorry for the jump start.

I - once again - updated the PR; now it should be ready for review 😉

[btecu]

Wouldn't defaultValue work for this?
I think it should work at least for undefined.

[pangratz]

I think this wouldn't work since defaultValue is only used when the value of an attribute is retrieved from a DS.Model, but not when an attribute is serialized...

[bmac]

Should we use Ember.get(options, 'allowNull') in case options is undefined?

[pangratz]

Theoretically options should never be undefined because of this and ultimately because of this.

It would only be undefined if the transform is used outside of regular ember-data usage...

[bmac]

Sounds good.

[sandstrom]

This is a great adjustment! 🎆

@bmac @fivetanley for 3.0, would you mind flipping the default of the option (or removing the option altogether)? In our app I'd say 99% of boolean values across all our models would use the allowNull option. Also, it's inconsistent with string, number etc. where no option is required.