TransactionSubscriber return a wrong max confirmation number

### Describe the problem you discovered

The transaction subscriber notify the client with the number of current confirmation for a transaction and the maximum number of confirmation.
This maximum number of confirmation is calculated by the welcome node it self using
```elixir
tx_address
|> Election.chain_storage_nodes(P2P.authorized_and_available_nodes())
|> Enum.count()
```
The problem is that this calculation do not take into account if the node is currently available or not. In the validation, the validation nodes ping all the replication node to know which one is currently, if a node do not respond no replication message will be sent to it.
So let's assume their is 4 replication nodes for a transaction but one is not available, there will be only 3 confirmations for the transaction, but the transaction subscriber calculate a maximum confirmations of 4.

So there might be some problem for a client using libjs, it will never have the full confirmation while it should have it when reaching 3 confirmations

### Describe the solution you'd like

We should find a solution to inform the welcome node of how many max confirmations the validations nodes calculated.

Start by tracing TransactionSubscriber's confirmation notification and the validation path that pings replication nodes. Review the Election.chain_storage_nodes and P2P.authorized_and_available_nodes calls described in the issue, then compare the welcome node's maximum with the responsive validation-node count. Done means the subscriber reports the reachable maximum so clients can complete at the final confirmation.

Written by the indexing model from the issue text.