Install transfers an OS package into the Target. No concurrent Install RPCs
MUST be allowed to the same Target.

The OS package file format is platform dependent. The platform MUST
validate that the OS package that is supplied is valid and bootable. This
SHOULD include a hash check against a known good hash. It is recommended
that the hash is embedded in the OS package.

The Target manages its own persistent storage, and OS installation process.
It stores a set of distinct OS packages, and always proactively frees up
space for incoming new OS packages. It is guaranteed that the Target always
has enough space for a valid incoming OS package. The currently running OS
packages MUST never be removed. The Client MUST expect that the last
successfully installed package is available.

The Install RPC allows the Client to specify the OS package version. If
the Target already has an OS package with the same version then there is no
need to transfer the OS package to the Target. If the Target does not have
an OS package with the same version, then the OS package is copied.

Scenario 1 - When the Target already has the OS package:

Client :--------------|--------------> Target
TransferRequest -->
<-- [Validated|InstallError]


Scenario 2 - When the Target does not have the OS package:

Client :--------------|--------------> Target
TransferRequest -->
<-- [TransferReady|InstallError]
transfer_content -->
...
<-- [TransferProgress|InstallError]
...
TransferEnd -->
<-- [Validated|InstallError]

On a dual Supervisor Target which requires installing the entire
system with one Install RPC, one Install RPC is sufficient to
install the package on all Supervisors.
On a dual Supervisor Target which requires one Install RPC per
supervisor, the Install RPC applies to the Active Supervisor unless
InstallRequest->TransferRequest->standby_supervisor is set, in which
case it applies to the Standby Supervisor. The Target MUST accept any
order of package installation.
On a dual Supervisor Target which requires installing the entire
system with one Install RPC, the package MUST be made available on
all Supervisors or none. If upon installation the package is absent
from either Supervisor, the Target will transfer to both Supervisors
overwriting the existing one.
On a dual Supervisor Target which requires one Install RPC per
supervisor, the Target MUST always attempt to copy the OS package
between Supervisors first before accepting the transfer from the
Client. The syncing progress is reported to the client with
InstallResponse->SyncProgress messages.

If a switchover is triggered during the Install RPC, the RPC MUST
immediately abort with Error->type->UNEXPECTED_SWITCHOVER.

Scenario 3 - When both Supervisors already have the OS package, regardless
of the value in Start.standby_supervisor:

Client :--------------|--------------> Target
TransferRequest -->
<-- [Validated|InstallError]


Scenario 4 - On a dual Supervisor Target which requires one Install RPC
per supervisor, and when one of the Supervisors already has the OS
package but the other Supervisor is the target of the Install:

Client :--------------|--------------> Target
TransferRequest -->
<-- [SyncProgress|InstallError]
...
<-- [Validated|InstallError]


Scenario 5 - When neither of the two Supervisors has the OS package:

Client :--------------|--------------> Target
TransferRequest -->
<-- [TransferReady|InstallError]
transfer_content -->
...
<-- [TransferProgress|InstallError]
...
TransferEnd -->
<-- [Validated|InstallError]

Activate sets the requested OS version as the version which is used at the
next reboot, and reboots the Target if the 'no_reboot' flag is not set.
When booting the requested OS version fails, the Target recovers by
booting the previously running OS package.

Verify checks the running OS version. During reboot, gRPC client returns
the gRPC status code UNAVAILABLE while the Target is unreachable, which
should be retried by the client until successful. After the Target becomes
reachable, it should report all ready or error states normally through
VerifyResponse.

On a dual Supervisor system, if the Standby Supervisor is rebooting, it
should be reported in the VerifyResponse via verify_standby as
StandbyState UNAVAILABLE.

The version that is required to be activated and optionally immediattely
booted.

For dual Supervisors setting this flag instructs the Target to perform the
action on the Standby Supervisor.

If set to 'False' the Target will initiate the reboot process immediatelly
after changing the next bootable OS version.
If set to 'True' a separate action to reboot the Target and start using
the activated OS version is required. This action CAN be executing
the gNOI.system.Reboot() RPC.

Standby Supervisor ID, usually the slot number.

The percentage that has transferred between Supervisors.

The number of bytes transferred.

The version string is a vendor defined string that identifies the OS
version. It is provided by the vendor and embedded in the OS package. This
value states the desired OS package version to transfer to the Target. If
the Target already has the OS package version it will reply with
InstallResponse->Validated. In the case that the target is a
single Supervisor device, or the partner Supervisor does not have the OS
image specified, it will respond with InstallResponse->TransferReady.
In this case, the client MUST subsequently transfer the image. In the case
that the image is available on the peer Supervisor of a dual Supervisor
system, it will respond with InstallResponse->SyncProgress. In this,
latter, case - the client does not need to transfer the OS image. This
value can also be set empty, in which case the OS package is forced
transferred to the Target. The Target MUST never validate that this value
matches the one in the InstallResponse->Validated message, that is the
Client's responsibility.
A dual Supervisor Target which requires installing the entire system
with one Install RPC, will either have the image on both Supervisors
or neither Supervisor. Such Targets do not need to sync the image
from peer Supervisor and MUST immediately respond with TransferReady

For a Target with dual Supervisors setting this flag instructs the Target
to perform the action on the Standby Supervisor.
A dual Supervisor Target which requires installing the entire system
with one Install RPC MUST return an error code of NOT_SUPPORTED_ON_BACKUP
if requested to install on standby only.

Optionally specify the package size in bytes of the OS package being
transferred.
If 1) the value is different than 0
and 2) the required space in the Target is larger than the available space
and 3) the Target is unable to release space for the incoming OS package,
then the Target must reply with InstallError->Type->TOO_LARGE.

The OS version string that identifies the OS version in the OS package.

Informational field that SHOULD be used for providing more details about
the OS package and its version. This MUST be strictly informational if
used, and can contain information such as build date, target platform,
developer, etc.

The OS version currently running.

Informational message describing fail details of the last boot. This MUST
be set when a newly transferred OS fails to boot and the system falls back
to the previously running OS version. It MUST be cleared whenever the
systems successfully boots the activated OS version.

Dual Supervisor Targets that require the Install/Activate/Verify process
executed once per supervisor reply with individual_supervisor_install set
to true

Standby state indicates problems with the standby.

Standby response indicates that the standby is present and ready.

Label to disambiguate path.

Elements of the path.

The name of the element in the path.

Map of key (attribute) name to value.

The gNOI service semantic version.