Oracle Enterprise Manager Cloud Control lets you discover, monitor, and manage an Oracle
Globally Distributed Database and its components.

If you are inserting new data from an application, you should work with one transaction for one customer at a time assuming your data is sharded by customer.

To load a lot of customers/orders/lineitems at a time, you might also use Data Pump.

Data Pump import can be run in parallel on all shards from the same dump file and each shard will ignore rows that do not belong to itself. 

It is certainly good practice to ensure high availability of shard catalog and shard directors.

One should associate a standby database to the shard catalog database for high availability or disaster recovery purposes.

You need at least a shard director per region, but can deploy up to five shard directors in a given region to achieve high availability and scalability.

Because Oracle Globally Distributed Database is based on table partitioning, all of the
subpartitioning methods provided by Oracle Database are also supported for sharding.

For instance, one might use system-managed partitioning for sharding by cust-id and sub-partition by date inside a shard:

(...)

PARTITION BY CONSISTENT HASH (cust_id)
SUBPARTITION BY RANGE (signup_date)

(...)

Sharding is a good architecture to provide high scalabiliy on a shared nothing architecture...only if your schema and application are compatible with processing a transaction locally once you have been routed to a shard according to your sharding key.

To process a DML transaction across data in multiple shards (as in your example), you would need to connect  using the GDS$CATALOG built-in service and use the shard catalog query coordinator as a proxy. This will work but will be slow and will ruin the scalability if you do it too often. It must be an exceptional transaction in your application.

A regular transaction to a sharded database service using a sharding key should connect you to just a single shard and will allow you to only modify data in that shard.

In a global architecture for data sovereignty, one might first split data by region ("sharspace"), with one shardspace only for India. In that Indian shardspace, one could have a shardgroup of 10 shards with RAFT replication inside this shardgroup. Indian data will then be replicated in India only. Other geographies will have their own shardgroups with their own RAFT replication.

Not if you use more than three shards. For instance if you have ten shards, each Raft Replication Unit will only be stored/replicated on three of the ten shards. And updates will normally be directed to the leading shard for the RU. It is a bit similar to a stripe and mirror architecture like ASM.

Fisrt of all you need to have a schema that it compatible with sharding: a hierarchical family of tables under your sharding key.

In Java, you will certainly have to modify the connection pool and the way you get and close a connection from that pool. 

Using Oracle's Universal Connection Pool is the best practice.

It is hard to answer to this question without more information about your architecture. Here are a few things to consider:

1. Sharding can use RAC for shards.
2. RAC is good for any application (as the name "Real Application Clusters" highlights), but Sharding is only possible if your schema and application are compatible with its constraints. You need to be able to "shard by something" and complete most transactions on the target shard for a given sharding key.
3. If 95% of your transactions happen for a known country and are using country specific data and you have a country-code in your tables, yes your might be able to migrate your apllication to a sharded architecture with or without RAC for shards.