WIP: Allow created_at to be passed by app

[andrepiske]

This PR changes the trigger function so that the resulting created_at attribute of a irontrail_changes record can be changed by the app by passing it in the _created_at metadata key.

This effectively allows apps to bypass postgres' NOW() function and inject any time they'd like. This is useful when creating tests that depend on mocked data. Even though it can be used in production too, it is not recommended.

The trigger function would use postgres' NOW() function to fill in the created_at attribute. Now, it'd to the following logic to determine the value for created_at:

1. If _created_at is set in the metadata map, then:
2. Use its value (must be a float number with epoch time, like in ruby's Time.now.to_f) to fill the created_at attribute
3. Set the _db_created_at key in the metadata to NOW(), so preserving what would have been filled by postgres. This could be useful for debugging.
4. Else (if _created_at is not set in the metadata map), then just use NOW() for the value of created_at

---

Caveats:

• This inserts another point of failure in the trigger function. If the value of _created_at isn't a floating point number, it'll crash and thus the record will end up in the errors table (irontrail_trigger_errors). The solution as I see it is to validate this in ruby's side by having a proper interface to set that value. i.e. we don't want users to do IronTrail.store_metadata(:_created_at, some_value_here) but to use something like IronTrail.use_soft_created_at(some_time_object) (that's probably a bad name)

---

Related tasks:

• INF-234

[andrepiske]

Closing in favor of #18