Clearer language for the Provider's time range query params

[manassra]

Is your feature request related to a problem? Please describe.

The language of the provider spec isn't clear on whether the time range query parameters for the /trips and status_changes endpoints are required or optional. If optional, the spec doesn't outline the default behavior for the data returned, even if paging is implemented. Should it be returning data since the beginning of time (with pagination)? Should it default to a given time period (example: last 24 hours)?

As the data exposed by providers grows, pagination becomes costly for very large time ranges. Some clarity in the spec would make it very helpful to optimize those edge cases.

Describe the solution you'd like

The provider spec should clearly outline whether the query parameters are optional or required, and whether it is ok for providers to return an error if they are not provided. If optional, the spec should clearly outline the default behavior.

Is this a breaking change

Potentially yes, for clients that expect to send requests without time range query parameters.

Provider or agency

Provider

Describe alternatives you've considered

We are currently considering an implementation that makes those fields required, but would like to confirm that this strategy does not violate the provider spec.

[thekaveman]

Thanks @manassra, this is an important clarification to make.

Assuming the current language of #357 gets merged for 0.4.0, which seems likely, we have not only changed the time query parameters for /status_changes and /trips, but also in each case the time query parameter will be required.

Additionally, #357 introduces a new endpoint /events with similar time query parameters as the current 0.3.x /status_changes, with an update that they are now both required.