`Client` should allow disabling automatic address book update

### Problem

Currently, the SDK updates the address book dynamically under the hood, and developers don't have options to configure this behavior. This automatic update can lead to unwanted or unexpected results in some use cases.

The automatic update feature is a nice-to-have feature, but there must be a way to stop it.

These are potential problems at the moment:
- There's no guarantee that the mirror nodes' address book is updated, and there's no way to prove it. To have the proof, you need to compare the result of the REST API call with an updated and approved file or querying the validators. Having a non-fully-updated MN is not so uncommon, i.e., I suggest clients run their own MN, starting the sync not from years ago but from the moment their business starts, and because of how the sync of the address book works, the MN starts with the original address book and updates it only when a new update transaction for `0.0.101` is executed and parsed. You can manually configure the mirror node to use an updated address book - we are considering providing a complimentary one in the repo for each release. Still, it's up to the MN provider to update that list, and the doubt remains from a developer's point of view.
- These doubts can cause developers to use well-known public mirror nodes instead of their own, creating a risk for live applications:
- As a mirror node provider, I can maliciously return a list created to include only nodes I care about so that all the fees go in that direction.
- As a mirror node provider, I can maliciously return an invalid list (i.e., wrong IPs or ports) so that I can create a DDoS spread across any SDK - and associated live applications - currently relying on my REST API
- I can configure my business network with a fixed list of IPs to connect with if I have a fixed list. With a dynamic list provided by external systems I don't control, I cannot properly configure my business network. So, I should assume any IP is a valid validator, which can be a serious problem in some constrained business environments, especially if this happens in a live application in production.
- With a default fixed address book for each specific SDK release, I can interact with older SDKs more easily. I.e., while collaborating in the creation of a scheduled transaction, I can avoid the use of nodes not recognized by default by that specific SDK, reducing potential issues in validating the transaction before applying signatures.

All the above things make me think the feature is an excellent addition to the SDK in some specific cases, but it should be optional and false by default (or true if we want to preserve retro-compatilibty).

As a side note about the static address book files in the SDK, here is why we should keep them:

- We still need to provide in the SDK a fixed/default list of public mirror nodes to read data from
- As an operator/developer/user, I need to access multiple servers (mirror nodes and main nodes) and configure my environment correctly even if I don't use the Mirror Nodes
- As a developer/user, I want to have the minimum amount of connections before being ready to work with the network, reducing the potential issues in case mirror nodes are unavailable or network issues.
- As a developer/user, I still would like to rely on a fallback and fixed list of approved main nodes. Hedera is still a permissioned network, so that list will remain primarily valid for many use cases.

### Solution

- Let the developer configure the address book automatic update activation
- If disabled, the SDK will relay only to the static address book provided with the release
- If enabled, let the developer configure the frequency of the update
- Let the developer override the default static address book for another address book file
- Provide the most updated address books for each network for each SDK release
- Intermediate minor SDK releases provide complimentary updated address book

### Alternatives

_No response_