Fix `associated_trip` schema inconsistency in 0.3.2

[rf-]

When I submitted #297, I was under the impression that the existing JSON schema allowed an associated_trip value for any event_type_reason. It turns out that this is incorrect and the schema only allows an associated_trip for user_pick_up and user_drop_off events. If an event with a different reason has an associated_trip, both branches of the oneOf clause are true and the schema validation fails.

Now that the spec unambiguously states that any event can have an associated_trip if it ends a trip, we should update the schema to be consistent with this. I'm not sure how schema-only changes have been handled w/r/t the versioning/release process so far.

[hunterowens]

yeah! schema only fixes have been treated as breaking in the past IIRC, but we should def fix this in time for 0.4.0 and perhaps consider an out of cycle patch release of 0.3.3 series.

(also sorry for not catching this sooner, I was out of pocket for a week).

Can you submit a PR and then @thekaveman and I can figure out what to with it

[thekaveman]

On the call today, the consensus from the group was that it is OK to wait for 0.4.0 to fix this.

If anyone has a different opinion, speak up on this issue ASAP!

[marie-x]

What other events besides user_drop_off can end a trip?

[rf-]

The classic example has been unavailable/low_battery, for the case where a trip ends involuntarily because the battery runs out and there’s no period of availability in between. This could also apply to maintenance.

[hunterowens]

fixed in #353