`resolveByDataSetId` doesn't check metadata consistency

[rvagg]

Thanks to #438 I'm noticing that when you select a specific data set it doesn't check your metadata matches. It only checks that withCDN matches. We need to figure out the strategy here and it's a little bit tricky.

In resolveByProviderId we do a metadataMatches using requestedMetadata. But in that case you're fishing for a matching data set, in the resolveByDataSetId case you've already explicitly selected one, so is it the SDK's business to be checking that it matches the metadata you requested. Currently we do some checking, withCDN must match the data set. So we're doing a half-way job, which isn't good. I think we should either go further, or do nothing:

Options:

1. Strictly require that requestedMetadata matches the data set and error if not (this value is made in resolveProviderAndDataSet and could just be moved up to before the call to resolveByDataSetId).
2. Only require that meta data matches if you provide some in your options - including withCDN being set. If withCDN && metadata are both undefined then perform no checks.
3. Perform no checks at all, including withCDN.

[rvagg]

@SgtPooki: I would appreciate your thoughts in here from an API consumer perspective - should you always have to show up with matching metadata and have Synapse validate? Or should you just show up with a data set ID and that's enough. But if you do add metadata to your options along with a data set ID, what are we to make of that? Ignore it, error because that's not allowed, or match it?

[SgtPooki]

@rvagg I prefer option 2 above.

When I provide a dataSetId, I usually won't pass metadata because I just want the specific dataSet identified by the given dataSetId. So synapse-sdk should not be calling metadataMatches in synapse-sdk (which requires EXACT Record<key,val> match).. If I do pass a dataSetId and metadata, synapse-sdk should throw an error because the metadata I provided doesn't match the dataSetId.. and I must care about the metadata if I passed it.

Other thoughts:

1. If I did care about metadata, I would probably just call createContext with metadata, and we should call a resolveDataSetByMetadata, or similar, internally.

2. We should probably normalize the withCDN/withIpni option sugar in the metadata earlier in the flow instead of using a separate options field internally i.e. merge withCDN/withIpni early

3. Do we want to handle partial metadata matches by giving users a way to do that? I just noticed when working on resolveByProviderId that I have a ton of load-test metadata where each dataset has a unique key, and so it's literally impossible for me to ever select one easily unless: 1. we have partial metadata matches, 2. I get all datasets and parse through the metadata of them to pick the one I want, 3. I do 2 to get ids and then use resolveByDataSetId