New syntax: AS OF FUTURE SYSTEM TIME

Is your feature request related to a problem? Please describe.
My request is to remove one of the last challenges faced by database users, and that's populating the database with data.

Database population suffers from the following two issues:

1. Importing can take a long time. The cluster cannot be used until there's data in there.
2. The database administrator needs to know the data in advance.

Describe the solution you'd like
A new variant of the current SQL syntax called 'AS OF FUTURE SYSTEM TIME`

An example:

First we create a new table:

CREATE TABLE users (
	id UUID PRIMARY KEY,
	first_name STRING,
	second_name STRING,
	credit_card STRING
);

Then, instead of populating this table with INSERT, RESTORE, IMPORT etc, we use the new AS OF FUTURE SYSTEM TIME syntax to get the data that will be there in the future:

SELECT * from users AS OF FUTURE SYSTEM TIME '+1 month' LIMIT 4;

                   id                  | first_name | second_name |   credit_card
---------------------------------------+------------+-------------+-------------------
  1738a731-da99-4c66-9748-6bcbdc6b06da | Bea        | Arthur      | ****************
  355913a3-1733-4286-8f19-07403dbf58bf | Betty      | White       | ****************
  35da69f6-8379-48ac-9ff9-ee00d6245d16 | Estelle    | Getty       | ****************
  452911b0-854d-428a-8b90-42dd848f96c2 | Rue        | McClanahan  | ****************
(4 rows)

Of course, I have removed the credit card information from the output for the purposes of this Feature Request (and also because these four users are as yet unaware they will add their details within the next month).

Some of the benefits go far beyond having the data already available. Right away, I can view which users will eventually sign up to my service, so I can send marketing advertising directly to these users and no-one else, bringing savings to my advertisement budget. In fact, I would have to make these users aware of my new service for them to sign up and avoid a universe-destroying paradox.

Credit cards would not need to be approved. By being in the system already pulled from the future data, they will have already been approved when they were entered in the future.

If I were selling items from a web-based store, I would know exactly how many items I needed to stock as I would know how many I have ... or rather will have ... sold.

The advantages are almost endless. In fact, if you build a prototype, you'll be able to see for yourself by running SELECT * FROM possibilities AS OF FUTURE SYSTEM TIME '+1 year';

Describe alternatives you've considered
Other alternatives include having custom hardware. For example, Google's Spanner uses hardware flux capacitors to jump their data into the future and return with it fully populated. Our solution enables every developer to build world-changing applications...soonish.

Jira issue: CRDB-14623