grpc-js: Re-add a couple of accidentally removed HTTP/2 session settings

[murgatroid99]

These settings were accidentally removed when refactoring the transport in #2855, as noted in #2855 (comment). This may have caused a regression that increased the frequency of RESOURCE_EXHAUSTED errors.

[emil10001]

In the future, we may want to figure out a couple of things:

• limit node's ability to allocate only memory that is available on the machine (as opposed to setting a fixed value that may be larger or smaller than the actual available memory
• figure out how to clean up memory for long-running node processes that we are operating in

[murgatroid99]

1. This limit is narrowly focused: it controls the amount of memory that each individual HTTP/2 session can have allocated at any given time. A process with N sessions would be able to allocate N times the limit in total for HTTP/2 sessions (which can exceed the available memor), and this is common because there is one session per connection, and it is common to use load balancing policies that create multiple connections. In addition, this limit does not affect any other allocations in the Node process, so it does not really prevent hitting any allocation limit in general.
2. The limit is already configurable via the referenced channel option, so users can limit it if their use case requires it.
3. I am not aware of any existing issues about cleaning up memory in long-running processes.