udpa: clarify URI fragment encoding of directives.

[htuch]

After spending some time looking at RFC3986 and chatting with Louis, it
seems we can support multiple directives in the fragment, but we need to
be very precise on how they are percent encoded.

This patch proposes that we move from having multiple fragments (which
are not allowed in RFC compliant URIs) to a single fragment with
comma-separated percent encoded directives. Comma was selected as it is
an available character in RFC3986 sub-delims, intuitively indicates
separation, and is less likely to appear in URIs (forcing percent
encoding) than other alternatives, e.g. '&' which would appear in most
URIs with context parameters.

Percent encoded directives in URIs should remain fairly readable, for
example udpa://foo#entry=something,alt=udpa://bar/baz&x=y requires no
percent encoding.

Signed-off-by: Harvey Tuch htuch@google.com

[htuch]

@markdroth @louiscryan for review

[markdroth]

I can live with this if it's the consensus, but I'd still prefer to use a repeated UdpaResourceLocator instead of having an alt directive. To me, the fact that we need so much machinery around encoding this in a URI is a pretty strong indicator that while we can make this work, that doesn't mean we should.

[markdroth]

Suggest removing the trailing . here, just to make it clear that that's not expected to be present in the format.

[htuch]

@markdroth if we did move #alt out in favor of an explicit fallback list, I think I'd still want to maintain this encoding machinery for other potential embedded URIs. The rational here is that we might one day want to do some kind of template composition and reference a base URI. I realize we're most definitely not going to do this in the current proposal, but leaving this flexibility in the addressing scheme seems to make sense, even if this is only used by intermediaries like Istio xDS proxy, etc.