Currently create_policy accepts an expiration datetime and a number of duration periods, but by default the policy becomes active either a) when the grant function executes or b) at the start of the next period (i.e. within 24h)

Some Alices, across various use cases, may wish to future-date their sharing policies. For example, a staking-as-a-service company setting up a new validator instance wants its access to signing keys (and the unique conditions for that access) to commence at a specific date in the future, such that this access is synchronised with other processes/infrastructure.

Arguably this future-dating could be configured on Alice's machine, since she needs to be online and connected to the network for the policy creation in any case. On the other hand, if a re-encryption key can be generated by Alice and held by Ursulas in advance, including the condition of delayed access to a Bob, this would surely enhance the Disappearing Alice source of value (@jMyles – that's for you <3)

This would impact the first_period_value & first_period_rate – see #1063

Future ideas: sharing policy start dates based on arbitrary conditions, not just a datetime. For example, if we end up with Ursulas actively ingesting block heights from various networks, then reaching a certain epoch could trigger access for a set of pre-designated validators.