orchestratord: Test defaults from our documentation

[def-]

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[jubrad]

We should probably provide a community license key to buildkite

[def-]

We have one (well, the developer key, not community), I'll put it in. Ideally we should have this documented too.

[def-]

Can we just set this in our provided sample yaml file to make life easier for customers?

[alex-hunt-materialize]

Shouldn't it be unique per customer, though?

[def-]

Then we should at least document a simple way to set it, ideally with a script that generates a uuid for them and puts it in automatically.

[alex-hunt-materialize]

Mostly looks good, but I'm not sure we should set the environmentId in the sameple, as most customers will end up sharing that environmentId or hitting issues when the environmentId doesn't match their license.