feat: Persist assert_integrity feature

[daogrady]

Fixes #1020

[patricebender]

We could already prepare for other supported feature flags in a generic way, because once another feature flag will be added, this should be done anyway. Something like

[daogrady]

I actually started with a generic implementation that would take an arbitrary path into the cds.env, prepare all parent objects in package.json based on the type of what cds.env dictated and finally copied over all appropriate values. And before I knew it, I had a 200 loc function, that somewhat paled in comparison to this 5 line solution for the problem at hand. 😃
I therefore suggest to keep it simple as long as we are dealing with only one value and generalise it later, if we need to carry over more settings.

[patricebender]

I see. However, I am not really happy with just fixing the passthrough for this one feature. I can imagine other feature flags which are important for a proper build, such as: naming modes (quoted or plain names?), standard database function mappings, …

@stewsk @johannes-vogel @chgeo we have the issue that build relevant options are not per default copied over to the postgres deployer app (found in gen/pg) do you have some idea how to properly copy over build relevant options (which are those?) to the deployer app? If we don't do that, an mbt build && cf deploy will lose all SQL relevant features defined in the app which e.g. has been the case for cds.features.assert_integrity in #1020

[johannes-vogel]

I don't think that there's a dedicated section for deployment relevant things. They are spread over different sections.

[patricebender]

Would it then in your opinion be sufficient to have a kind of allow-list approach, where we selectively copy over known build relevant options?

[johannes-vogel]

I don't know if an allow list makes sense if we do not know the options. How is that solved for the hana deployer?

[patricebender]

during build for HANA the actual db artifacts are already created with all features found in the cds env. Upon a deployment the hdi artifacts already have the desired features baked in. In contrast to that, for postgres, only a inferred CSN is generated during build. Which does not contain any DB specific transformations, hence lacking the DB features set in the cds env. Upon deployment, the gen/pg/csn.json is transformed to the actual SQL schema. If the deployment is initiated in the gen/pg/ folder, the root app cds env is ignored in favor of the the cds env of the deployer app (gen/pg/package.json) which is empty, invalidating all features set in the apps root.