use drive discovery key for drive ids

[achou11]

Closes #272

Stacked on #290

This PR:

• updates BlobStore to use discovery keys instead of public keys for drive ids
• renames the driveId field of the BlobId type to driveDiscoveryId, to align with the issue's desire to update the observation attachment reference.

I initially thought we may want to rename driveId used in the blobs-related code to driveDiscoveryId but then realized that we may not want that. If we want to revert the naming, just a matter of reverting the last commit on this PR.

[gmaclennan]

Looks good to me. Not sure about the naming question. Internally, it makes sense that it is called driveDiscoveryId, since that describes what it is, but for the API consumer, I think driveId makes sense, because for the API consumer it is just "ID that identities the drive the blob is stored on", and we don't expose any other ID to the API consumer.

In summary, I think maybe call it driveId where the API consumer sees it, even though that makes it a little confusing when reading the internals - just make sure to add comments.

[achou11]

yeah all of that came to mind as I was implementing.

One question I have then is should the return value of BlobApi.create() contain a field called driveId or driveDiscoveryId? Your suggestion seems to suggest the former, but my understanding is that the latter would be more convenient because you could directly use the return value as the value for an observation attachment (which uses driveDiscoveryId based on the schema change)

EDIT: leaning towards driveId despite the minor inconvenience when it comes to observation creation/update, as the blob API shouldn't necessarily be strictly tied to the schema def of a particular datatype

[achou11]

Decided to basically revert the renaming entirely, without attempting to strategically update naming for internals. Just became confusing and I think for now the comments are helpful enough. Can revisit if it really does become super confusing