Document grpc-js supported channel args in readme

[josephharrington]

This copies the list of supported channel arguments from PACKAGE_COMPARISON.md into the readme, and also adds a link to the package comparison doc.

resolves #1982, resolves #1983

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Joey Harrington (5623c4e)

[murgatroid99]

I am OK with this overall plan but I don't like how this list of supported channel options overwhelms the rest of the "Migrating from grpc" list. I would prefer to have a separate "Supported channel options" heading with this list and a brief explanation. Then the bullet point in the "Migrating from grpc" can have a brief explanation of what the user should do to migrate from grpc when they are using an unsupported channel option, including a reference to that other heading.

In order to avoid duplicating information that needs to be updated, I would prefer to also remove this information from the package comparison doc and replace it with a link to this README, saying something either about channel options in particular or API differences in general.

[josephharrington]

@murgatroid99 Good points! Thanks for the feedback.

a brief explanation of what the user should do to migrate from grpc when they are using an unsupported channel option

For this, I think the best recommendation would just be to remove usage of any unsupported channel options. Can you think of anything else they should do?

[murgatroid99]

I don't think that really addresses the main issue. Removing unsupported options is not necessary because grpc-js just ignores unrecognized options, and if the option ever is supported in the future, it will have the same semantics. The more important thing is for users to be aware of options that are not supported, and adjust their own code to compensate. In your own example in #1982, your problem was not solved by removing the unsupported option, but by finding and using the alternative option that provided the desired functionality.

So, maybe it could say something like this:

If you are using any channel options supported in grpc but not supported in @grpc/grpc-js, you may need to adjust your code to handle the different behavior. Refer to...

[josephharrington]

@murgatroid99 Yep, agreed! I updated the change with the wording you suggested.