feat: Add TableDataService#getRawTableLocationProvider

[arman-ddl]

Satisfies #6001.

[rcaudy]

Trivial review. This appear to be in the spirit of what we discussed, I just think we should be more precise in the documentation. Darin's comments re: correctness seem valid.

Originally, I thought looking up a raw TLP should not apply filters, but I'm convinced you've made the right call; the TLP is raw, but which TLP we select still applies the TDS's rules.

[darinpetty]

With the two comments below, it looks like you could end up with multiple services that cause a false collision in CompositeTDS. If CTDS has (directly or indirectly) two FilteredTDSs that could potentially handle the TLK, both will be returned and you will get an error, even if you have crafted a system where they don't actually collide, as in the LTDS scenario I described in slack.
I think the fix is to query each candidate TLP with hasTableLocation to find out if it actually has a location, not just might have it.

[arman-ddl]

With the two comments below, it looks like you could end up with multiple services that cause a false collision in CompositeTDS. If CTDS has (directly or indirectly) two FilteredTDSs that could potentially handle the TLK, both will be returned and you will get an error, even if you have crafted a system where they don't actually collide, as in the LTDS scenario I described in slack. I think the fix is to query each candidate TLP with hasTableLocation to find out if it actually has a location, not just might have it.

Darin's observations makes me think about a couple more things:

1. Should we also be TDS#reset'ing if the TLP does not hasTableLocationKey since the TLP we create is not actually going to be used?
2. Going even further, should the TDS interface instead have a hasTableLocationKey method to accompany getRawTableLocationProvider so we don't have to do an unnecessary TLP creation and/or reset?

[rcaudy]

With the two comments below, it looks like you could end up with multiple services that cause a false collision in CompositeTDS. If CTDS has (directly or indirectly) two FilteredTDSs that could potentially handle the TLK, both will be returned and you will get an error, even if you have crafted a system where they don't actually collide, as in the LTDS scenario I described in slack. I think the fix is to query each candidate TLP with hasTableLocation to find out if it actually has a location, not just might have it.

Darin's observations makes me think about a couple more things:

1. Should we also be TDS#reset'ing if the TLP does not hasTableLocationKey since the TLP we create is not actually going to be used?
2. Going even further, should the TDS interface instead have a hasTableLocationKey method to accompany getRawTableLocationProvider so we don't have to do an unnecessary TLP creation and/or reset?

1. Reset is too heavy of a hammer. Realistically, if you're doing this, how likely do you think it is that the TLP doesn't already exist?
2. I don't known if you need that.

Maybe you could take Darin's suggestion and go one step further: if the TLP doesn't exist at some level, or no TLP is found that has the TLK in question, return null from getRawTableLocationProvider.

[arman-ddl]

With the two comments below, it looks like you could end up with multiple services that cause a false collision in CompositeTDS. If CTDS has (directly or indirectly) two FilteredTDSs that could potentially handle the TLK, both will be returned and you will get an error, even if you have crafted a system where they don't actually collide, as in the LTDS scenario I described in slack. I think the fix is to query each candidate TLP with hasTableLocation to find out if it actually has a location, not just might have it.

Darin's observations makes me think about a couple more things:

1. Should we also be TDS#reset'ing if the TLP does not hasTableLocationKey since the TLP we create is not actually going to be used?
2. Going even further, should the TDS interface instead have a hasTableLocationKey method to accompany getRawTableLocationProvider so we don't have to do an unnecessary TLP creation and/or reset?

1. Reset is too heavy of a hammer. Realistically, if you're doing this, how likely do you think it is that the TLP doesn't already exist?
2. I don't known if you need that.

Maybe you could take Darin's suggestion and go one step further: if the TLP doesn't exist at some level, or no TLP is found that has the TLK in question, return null from getRawTableLocationProvider.

I'm thinking of a couple ways to determine "if the TLP doesn't exist at some level":

1. Adding hasTableLocationProvider method to TDS or ATDS
2. Changing AbstractTableDataService#tableLocationProviders from private to protected

Are you fine w/ either? If not, how do you propose going about it?

[arman-ddl]

Off-GH, Ryan helped me realize the issues associated w/ the default TDS#getRawTlp impl. Removing it and adding an ATDS#getRawTlp impl seems to address both Darin's and my concerns.

[rcaudy]

LGTM