Store the project estimate data in the data store

[vikasrohit]

As of now, the project estimation is just front end calculation that we show during project creation and we don't store it in the data store which makes it difficult to see what was the estimate we offered to the customer at the time of project creation. It becomes more difficult to track and understand if we need to change the price or time effort config for the same project template after project is created. We have no way to understand what was shown to the customer at the project creation.

fyi @maxceem @RishiRajSahu

[vikasrohit]

@maxceem We need to wrap this one quick as we want to push these changes to production with our next release so that we don't loose any data once we release the new smart forms on the production.

As a starting pointing I am suggesting to store the information regarding the price/time estimate in following table structure:

id bigint primary key,
buildingBlockKey: string not null, // e.g. SMALL_DEV_ONE_OS_NO_CA
conditions: string not null, //e.g. ( HAS_DEV_DELIVERABLE && (ONLY_ONE_OS_MOBILE || ONLY_ONE_OS_DESKTOP || ONLY_ONE_OS_PROGRESSIVE) && SCREENS_COUNT_SMALL && CA_NOT_NEEDED)
price: double not null, // e.g. 31000
minTime: int not null, // e.g.  3
maxTime: int not null, //e.g. 5
metdata: json default {}, // e.g. { 'deliverable' : 'dev-qa' }
projectId: bigint not null, // eg. 5425

(along with regular audit fields)

Essentially, I am trying to keep everything that is related to the price estimation and we have it available at the time of project creation. We have to send all building blocks that we used to estimate the price and time effort for the project at the time of project creation and simply each building block as single record.
We are still open for suggestions, however, for now we have to just have the data in database. We can later optimize or change the structure of this table or the process when we introduce new work management process in Connect which would require to use this information very frequently. So, we have to decide at that time the optimal structure for this. However, it is still good to have it in a way which causes minimum changes at that time (I guess that time is not too far as well).