don't validate license key audience

[jubrad]

Motivation

I'm not actually sure that we want to do this, but it's quite possible we do. The audience should have to match, but in practice this will be very difficult to coordinate with community license keys and transitions to enterprise.

I think we should consider warning if the audience doesn't match. We may also want to consider investigating process changes to allow us to keep this check.

Tips for reviewer

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.