Consider adding an upper bound on the number of root metadata we'll fetch in Client::update_root

TUF-1.0.9 §5.1.2 states:

Try downloading version N+1 of the root metadata file, up to some W number of
bytes (because the size is unknown). The value for W is set by the authors of
the application using TUF. For example, W may be tens of kilobytes. The filename
used to download the root metadata file is of the fixed form
VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,
or we have downloaded more than Y number of root metadata files (because the
exact number is as yet unknown), then go to step 5.1.9. The value for Y is set
by the authors of the application using TUF. For example, Y may be 2^10.

We do not have an upper bound on the number of root metadata we'll fetch. This means that an attacker that's stolen the root keys could cause a client to fall into an infinite loop (but if an attacker has stolen the root keys, the client probably has worse problems to worry about).

Start at Client::update_root and trace the loop that downloads successive root metadata versions. Check how application-configured TUF limits are represented, then determine where a configurable upper bound on fetched root files belongs. Done means the update process stops after the configured limit, with behavior covered by tests for the bound.