Thoughts on a synchronous rcl.init() function #757

Presently rcl.init() (see index.js) is an asynchronous function due to it's file system access to detect format changes in generated message files. I would like to open a discussion around the idea of adding a synchronous version of init(), e.g., rcl.initSync(), rcl.basicInit() or rcl.fastInit(), which either does not perform file system access or includes the ability to opt out of automatic message version check and regeneration.

A use-case is the rate.js implementation that creates a private rcl environment using it's own context. Because the implementation has to call rcl.init(privateContext) the Node.createRate() method is unnecessarily async. I say unnecessarily async because rate.js has no dependencies on generated msg files yet it inherits that overhead from rcl.init().

Thoughts?

One impl may look like this:

let rcl = {
...
 fastInit(context=Context.defaultContext(), argv=process.argv) {
 // check if context has already been initialized
 if (!context.isUninitialized()) {
 throw new Error('The context has already been initialized.');
 }
 // check argv for correct value and state
 if (!Array.isArray(argv)) {
 throw new TypeError('argv must be an array.');
 }
 if (!argv.every((argument) => typeof argument === 'string')) {
 throw new TypeError('argv elements must be strings (and not null).');
 }
 rclnodejs.init(context.handle, argv);
 },
 async init(context=Context.defaultContext(), argv=process.argv) {
 this.fastInit(context, argv);
 
 // do version check and update of generated msg files
 },
 ...
}