Tenant start and end dates

===========================================================================
Notes from Adam Young

 Dina Belova: I believe that should not be done in such direct way, really.
Why not using project.extra field in DB to store this info? Is that not appropriate for your ideas or there will be problems with there implementing using extras?

Adam Young:   It would not make sense to enforce on something that was not queryable directly in the database. Please don't use extra. I'd like to see it removed. It certainly should not be used for core behavior.

I think start/end datetimes make sense, and could be part of the project itself. Please write up the blueprint.

===========================================================================
cmart

Regarding the first two work items, we should add extra validations for dates, like:

* dates need to have an specific date format (the one used on Climate, a possible consumer of this type of data, is "%Y-%m-%d %H:%M")
* dates can be lower/earlier than current date
* also, we should analyze what could happen if only the one of the dates (start or end) is provided. For instance, if we have a request with a json like:
    {
       "tenant":
       {
           "description": "A new tenant, created with start and end date",
           "enabled": true,
           "start_date": "2014-05-21 12:30",
           "name": "myTenant"
       }
    }
(i.e: without a end-date) what should happen? 400 Bad request ?
Same case when only the end_date is provided.

Any thoughts?

Work items:
[cristian-a-sanchez] add start_date and end_date to the project table as a sql migration: TODO
[cristian-a-sanchez] add start_date and end_date to the project entity in assignment backend: TODO
[cristian-a-sanchez] add check for dates in TokenProvider when checking project enabled: TODO
[cristian-a-sanchez] ensure token duration is not past project end date in TokenProvider: TODO
[cristian-a-sanchez] Add scheduled notification for when project becomes disabled: TODO