`tf.data.Dataset` cannot yield `AnonymousTuple`, so it must have been
constructed by TFF with an appropriate Python container already, so we don't
need to do anything.

PiperOrigin-RevId: 322402388

PiperOrigin-RevId: 322400322

Binds references to remaining call construction sites in `ValueImpl`, cleans up tests depending on old behavior.

PiperOrigin-RevId: 322394328

Fix error-checking logic for `get_canonical_form_for_iterative_process()` for `IterativeProcess`'s with no aggregation.

The logic was previously failing for this case, but with a harder to grok error message.

The previous logic had a slight bug in the branching logic, such that we would never hit the explicit `ValueError` in the final `else:` block.

The tests were also incorrectly passing because they hit a different validation check:

```
ValueError: Expected an AST containing an intrinsic with the uri: federated_secure_sum, found none.
```
PiperOrigin-RevId: 322385240

PiperOrigin-RevId: 322377616

Also while were here, update to some more modern TFF coding practices:
-  Use `tff.learning.framework.ModelWeights` instead of a custom type.
-  Delete `from_tff_result` conversion helper, it is no longer needed.
-  Remove unused test helper methods.
-  Replace numpy dependency with TF ops.

PiperOrigin-RevId: 322359152

PiperOrigin-RevId: 322264433

PiperOrigin-RevId: 322257637

PiperOrigin-RevId: 322256044

PiperOrigin-RevId: 322249517

This is a pattern we have used frequently (e.g. in ReferenceResolvingExecutor's evaluate method) to persist more  information in traces.

Currently a little difficult to narrow down hotspots in serialization code.

Additionally adds PyType annotations and cleans up the contracts a little bit, easier with this new factorization.

PiperOrigin-RevId: 322246977

This will preserve the returned container value, making it usable with utilities such as `tf.nest`.

PiperOrigin-RevId: 322236441

- Remove use of `tff.NamedTupleType` and use Python containers and avoid
  exposing AnonymousTuple.
- Add handling of `tff.SequenceType` to type conversion code.
- Change ReferenceExecutor to convert values unconditionally.

PiperOrigin-RevId: 322232543

PiperOrigin-RevId: 322178848

Previously, NamedTupleTypeWithPyContainerType was often lost and turned into
a NamedTupleType without the container. This resulted in users being given
AnonymousTuples when a more specific container should have been returned.

This change fixes a large number of sites where container types were lost, and
adjusts usage sites as appropriate, including the removal of `from_tff_result`
functions.

This change also makes the `__eq__` function for
`NamedTupleTypeWithPyContainerType` require equivalent container types, rather
than just equivalent field structure. Call sites that wished to compare only
field structure are adjusted to use `Type.{is, check}_equivalent_to`.

PiperOrigin-RevId: 321883012

PiperOrigin-RevId: 321852405

stackoverflow so it can be passed to the iterative process.

Make shuffling conidition on the buffer size.

PiperOrigin-RevId: 321846124

Extend iterative process builder and the LR scheduling iterative process to accept an optional"datasset preprocessing computation.

This allows for pushing the dataset preprocessing methods down to the client
executors, which is required for multimachine simulations since stateful
datasets (e.g. datasets which suffling) cannot be serialized.

PiperOrigin-RevId: 321835968

The zeroing threshold is adapted to a multiple of a specified quantile of the value norm distribution.

PiperOrigin-RevId: 321831230

PiperOrigin-RevId: 321812938

PiperOrigin-RevId: 321790124

PiperOrigin-RevId: 321785542

PiperOrigin-RevId: 321657180

PiperOrigin-RevId: 321639468

PiperOrigin-RevId: 321617729

PiperOrigin-RevId: 321611005

A problem shows up with using subclasses of `tff.learning.Model`: after wrapping the model as an EnhancedModel, one cannot access the methods that are specifically defined by the subclass model.

This CL removes the EnhancedModel wrapper used when computing baseline metrics and training personalized models. This makes sure that users can access the full functionality of the model returned by `model_fn`.

PiperOrigin-RevId: 321578480

PiperOrigin-RevId: 321431928

PiperOrigin-RevId: 321423023

* Removed the `tff.framework.set_default_executor` API.
* Updated the callers to use the higher-level convienent API `tff.backends.*` instead.

PiperOrigin-RevId: 321421612

PiperOrigin-RevId: 321411362

PiperOrigin-RevId: 321393738

PiperOrigin-RevId: 321378169

PiperOrigin-RevId: 321268189

PiperOrigin-RevId: 321266409

PiperOrigin-RevId: 321265603

This change adds a compiler function to the `ExecutionContext` object. Conceptually a `Context` can be thought of as an "environment" which owns compilation and owns execution for a given computation. Additionally, this change replaces `set_default_executor` with higher level functions in order to simplify how contexts are constructed.

* Added compiler function to the `ExecutionContext`.
* Deprecated `set_default_executor`.
* Removed all usage of `set_default_executor` internally.
* Added convenience high level functions that set an execution context:
  * tff.backends.native.set_local_execution_context
* Updated `set_default_executor` call-sites to either use the convenience high level functions or to manually construct a context and use `set_default_context`.

Note that we should consider creating the following convenience high level functions:
  * tff.backends.native.set_remote_execution_context
  * tff.backends.native.set_sizing_execution_context
  * tff.backends.iree.set_iree_execution_context

PiperOrigin-RevId: 321263709

Semantic changes:
-  Use the LR schedule with round 0 during the server intializiation.
   Previously this relied on the optimizer builder specifying a default for the
   learning rate, which was overriden in later rounds. Explicitly call with a
   "round 0" learning rate to ensure the documented type is adhered to. This
   can be seen in the type annotations for the `server_optimizer_fn` argument
   to `build_server_init_fn` and `build_fed_avg_process`.

PiperOrigin-RevId: 321237803

Taking string rep of flattened ndarray can cause non-equal ndarrays to hash to identical values.

E.g., added test here failed previously--arrays that have identical values on the ends of their flattened reps, but differ in the middle, will result in the same key.

PiperOrigin-RevId: 321234171

PiperOrigin-RevId: 321234129