[BP MB-43252 to 6.6.3] TCP connection leaks in Indexer code

Three TCP connection leaks in Indexer production code from calls into security/tls.go PostWithAuth():

1. registerGlobalRebalanceToken() – indexer/rebalance_service_manager.go
2. Console() – common/util.go
3. makeScheduleCreateRequest() – manager/client/metadata_provider.go

#1 introduced 2016-11-10. (resp.Body.Close() added 2017-03-27.) Closes response body but does not read to the end of the body first. (local postWithAuth() calls security.PostWithAuth().)

#2 introduced 2019-02-20. Closes response body but does not read to the end of the body first. This code attempts to close the response body even if the TCP call failed, so it could produce a nil pointer dereference failure.

#3 introduced 2019-05-30. Only reads response body if the TCP call succeeded but the HTTP status reported an error (i.e. in the normal, success case it will not read the response body). Never closes the response body.

security.PostWithAuth() returns client.Do() which requires the caller to both read to end of response body and close response body to avoid leaking the TCP connection. From Go internal doc of client.Do() method:

// If the returned error is nil, the Response will contain a non-nil

// Body which the user is expected to close. If the Body is not both

// read to EOF and closed, the Client's underlying RoundTripper

// (typically Transport) may not be able to re-use a persistent TCP

// connection to the server for a subsequent "keep-alive" request.