GenerateSmartDefaults and changed behavior of NULL column with DEFAULT constraint causes unexpected data added to tables

• SqlPackage or DacFx Version: 161.8089.0 and higher
• .NET Framework (Windows-only) or .NET Core: all
• Environment (local platform and source/target platforms): all

Steps to Reproduce:

This seems to have been caused by the change made in #38

I have discovered this seems to have introduced an unexpected behavioral change.
This "GenerateSmartDefaults" property is documented as:

Automatically provides a default value when updating a table that contains data with a column that does not allow null values.

Now this property seems to be forcing values into new columns that are defined as allowing NULL, which is not what is documented, and not what was happening in previous versions of DacFx.

We are now forced to turn off the "GenerateSmartDefaults" flag, as we do not want data in new columns that are defined as NULL.

Consider the case where we have this table in release 1:
CREATE TABLE transactions (
item_id bigint NOT NULL,
price DECIMAL(16,6) NOT NULL
)

Consider this table might have billions of records.

In a later release, we change it to capture the date, expecting to get this filled for new records only :
CREATE TABLE transactions (
item_id bigint NOT NULL,
price DECIMAL(16,6) NOT NULL,
tran_date DATETIME NULL CONSTRAINT [df_transactions_tran_date] DEFAULT (getutcdate())
)

If we deploy this dacpac with the GenerateSmartDefaults enabled, the process now generates the upgrade statement:

ALTER TABLE [dbo].[transactions]
ADD [tran_date] DATETIME CONSTRAINT [df_transactions_tran_date] DEFAULT (getutcdate()) WITH VALUES NULL,

Previously it would not have included the "WITH VALUES". Now that it does include "WITH VALUES" it results in the current datetime being added to every record of the table, which is not the intent. This is a major data issue.

I consider #38 was a breaking change, and would suggest it should be re-worked to have a different flag to GenerateSmartDefaults enable it.

Did this occur in prior versions? If not - which version(s) did it work in?

This worked in SqlPackage in all versions prior to when the the fix went in for #38

Start by reproducing the documented GenerateSmartDefaults scenario with the transactions table and nullable tran_date column, then inspect the behavior introduced by #38. Done means deployment does not add WITH VALUES for a nullable column with a DEFAULT constraint, while the documented smart-default behavior for non-nullable columns remains intact.