… of a setRequestManager method

When using `.on<event>=fn` to attach listeners, only one listener can be
set at the same time. Since multiple request managers can use the same
provider, the EventTarget API has to be used to ensure all of them
receive the events emitted from the provider.

This is needed on both the `on` and `removeListener` functions.

The method `once` is required to allow the subscription logic to
identify if the provider is able to reconnect/resubscribe and then
attach to the following `connect` event the function to resubscribe.

When the subscription fails on start and when it fails after it was
successfully established, the same logic needs to be executed: remove
subscription, listen for the next `connect` event if available to
actually subscribe again, emit the error and call the callback.

Prior code did that only for established subscriptions so if a
subscription was unable to be set right on start, no resubscription was
ever tried.

The logic was moved to a single method to avoid duplication of code.
In addition reentry is avoided by checking and properly clearing the
`_reconnectIntervalId` variable.

On subscribe, if there is an existing `id`, the subscription listeners
are removed. In the case of a resubscription, the listeners have to be
kept. Therefore, the `id` property -that will change anyway- must be
cleared so the listeners are not removed.

Then, after the subscription object resubscribes, the listeners set by
the subscription user code remain untouched, making the resubscription
transparent to the user code.

When the request manager removes a subscription due to an error, it
tries to send an unsubscribe package, which can also fail if i.e. the
network is down. In such a case, the function must not allow reentry.
Removing the subscription first ensures it will not do so.

In addition, if the subscription was already removed, the callback shall
be called anyway.

When error events are emitted by the provider, all subscriptions shall
receive the event and trigger the unsubscription/resubscription logic.

By wrapping the available WebSocket implementation (native WebSocket
object or `websocket` package) with `websocket-reconnector`, the
provider is given a WebSocket that will automatically reconnect on
errors.

A new option was added to the WebSocket provider to controll whether it
should automatically reconnect or it should behave as usual.

In the case any websocket call takes too long to return and a timeout
was set for the provider to timeout, the provider should try to restart
the connection.

This could happen, for instance, if the client loses connection with the
server, the server closes the connection and later, the connectivity is
up again but since the client did not receive the closing frame *and*
the client does not attempt to send any package to the server, no error
is observed.

`websocket` implementation for Node.js has an option to send keep-alive
frames and detect such scenarios, but the standard browser W3C WebSocket
does not, so it is "vulnerable" to this kind of failure which will
mostly affect web3 subscriptions.

If the provider silently recoonects and emits a new "connect" event, the subscriptions have to be set again over that new connection.

Co-Authored-By: cgewecke <christophergewecke@gmail.com>

…cribing after the connection got lost will now get triggered from the RequestManager instead of the subscriptions

…ion.js and funcDoc added to websocketprovider.send()

…ms instead of clearing it after. Who knows the connection could got interuppted 1ms after the connect event got emitted

…e-sending or rejecting of the requests if the event connect or close got emitted

…r message updated

…nted

…3 added to dependencies of the web3-providers-ws package

… position moved of emit(event) in some provider listeners

…empts is reached and parseURL helper moved out to helper file because of ethical reasons

…ivate defined

…ketProvider for consistency reasons with _addSocketListeners

…ver it and is also configurable

…ubscriptions as well

… of the websocketprovider.disconnect() method. It will otherwise not close the connection if re-connecting is enabled

…he RequestManager and provider event name properties are now used in the RequestManager

…send methof of the WebsocketProvider object

… not trying to reconnect

…reconnect options extended/improved for the WebsocketProvider

…p object instead of a plain data object

… requied updated

…ring debuging

…etProvider. Test test is succeeding but it does trigger the reconnecting process again because I can't close the ganache server cleanly

…tProvider.send improved

…od of the WebsocketProvider

…ose listener of the RequestManager for subscriptions improved

… the new way the RequestManager does get inherited

…h using of a Map

…ketProvider.send

…ng the requestQueue to listen for close or event errors during execution of the request. (fixes a bug where transactions could get executed twice on reconnecting)

…vider

…e provider is reconnecting because of a manual call or because the reconnecting option auto is set to true

…finished request do now get handled if the provider does start to reconnect

…t queue changed

…che process in a clean way