Support new scheduled charging

[patrickdemers6]

Adds support for weekly charging schedules.

Description

Building off of #296

Fixes #290

Type of change

Please select all options that apply to this change:

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Bug fix (non-breaking change which fixes an issue)
• Documentation update

Checklist:

Confirm you have completed the following steps:

• My code follows the style of this project.
• I have performed a self-review of my code.
• I have made corresponding updates to the documentation.
• I have added/updated unit tests to cover my changes.

[sethterashima]

We're going to have a lot of churn if different people are using different protoc versions to generate these files. Not a big deal, but it does make it harder to tell at a glance if a .pb.go file was modified in a substantive way without a corresponding update to the proto source file.

Things to consider for future PRs:

• Could we generate the pb.go files automatically at merge time?
• Short of that, could we regenerate the pb.go files and check for discrepancies as a pre-merge check?
• If we do the latter, we should include a Dockerfile for building the proto files using a fixed protoc version.

[patrickdemers6]

good callout, created #307

[patrickdemers6]

Updated to generate with the proper protoc version. Looks like there are still a few unnecessary changes but much better.

[patrickdemers6]

@sethterashima this deserves a version bump. Do you prefer bumping version as a part of this PR or a followup PR which is deadicated to the version bump? Minor or patch?

[agbpatro]

nit: can we support generating protobufs in makefile?
https://github.com/teslamotors/vehicle-command/blob/main/Makefile
we do something like this in fleet telemetry as well

[patrickdemers6]

See above. created #307 to improve our proto generation.

[sethterashima]

@sethterashima this deserves a version bump. Do you prefer bumping version as a part of this PR or a followup PR which is deadicated to the version bump? Minor or patch?

Backwards compatible API changes should be a minor version bump. I've been stingy with the version bumps in the past, but if we're moving to a bump with each new feature my preference would be to include a version bump in the same PR.

Versioning rules are lax in 0.x.x releases, but we should also decide if we're ready to move up to a 1.0.0 release.

[patrickdemers6]

Bumped to v0.2.0. I would say version bumps are only necessary when changes people will want to use immediately are made.